Somebody recently repeatedly deleted some definition summaries of "types" at WhatAreTypes believing them to be fundamentally flawed. * Actually someone didn't delete them. I moved them to the bottom of the page, then to a side page, when the real offender wanted them to take the first paragraph position. The reason for doing that is simple: you cannot give everybody's 2c equal weight unless you want to bury the good ideas among piles of worthless stuff. I did every reasonable effort to explain to Top why there was one prevalent idea accepted by the scientific community (ComputerScience that is) and most software engineers, and how the "competing" alternatives were either subsumed by the main definition or they were not really definitions, or they were on the wrong track. -- CostinCozianu Even if they were flawed, shouldn't they be allowed to exist? * no, if ideas are flawed they should not be allowed to exist as such. At the very least they should be moved to side pages, clearly marked as discussion of flawed ideas. The primary responsibility is not to be courteous to authors behind flawed ideas (after all they should learn that CriticsAreYourBestFriends), but to be courteous to WikiReaders. If they come to learn or just to read, having to sift through "everybody's equal 2c" style of pages is not very helpful. [Also see EveryoneHasHisOpinion.] Reasons for deleting: * May confuse or mislead readers * Might be utter nonsense, disproven by prevailing theory (note that theory != conjecture). ** ''Then place the proof next to the item, but still leave it. You have not explained why the existence of counter-proof should result in outright deletion.'' Reasons against deleting: * One can rebut without deleting * Bad ideas need to be answered. If they are not answered then they may keep popping up. '''Those who don't know history are bound to repeat it.''' * They may not be wrong after all. Computer science is a soft science for the most part with few or no absolutes other than perhaps performance issues. (See DisciplineEnvy) * The two sides may be arguing about different issues, but not know it because they use the same word to mean different things. ** Actually, the conjecture is trivially false. One side, CostinCozianu that is, fully knew what it was all about. *** perhaps in that case but this page might be useful for other edit wars * Failure Analysis - Allegedly "wrong" thinking can be quite '''useful to teachers''' and documentation writers who are interested in how incorrect notions come about so that they can be corrected or prevented. Being a good teacher requires this kind of insight. It's roughly comparable to analyzing plane crashes to understand how to build better planes in the future. [See Note 1] ---- I notice that one or more of the proponents of heavy deletion who are against EvenBadIdeasShouldBeKept appear to have come from a European background. Europeans are more likely to accept the idea of "appointed experts" determining, even dictating "best practices". However, the US tends to let Darwinian market-forces and "populist" thinkers battle it out among themselves, not trusting authorities nearly as much. From an economic standpoint, both approaches work (with various tradeoffs). Thus, I wonder if there is some continental influence to the EditWars. I am not making accusations, only trying to figure out the motivations and culture of the edit warriors to perhaps make better compromises. -- TopMind ''Pointless stereotyping. I'm a European who thinks that EvenBadIdeasShouldBeKept (usually, although that doesn't mean that there are not particular WikiPage''''''s that are completely redundant). -- DavidSarahHopwood'' Stereotypes are not necessarily false. For example, if polled, I bet Europeans would on the average answer differently. But that does not mean that every individual votes the same. ---- Actually, we see again TopMind whining beside the point. We keep bad ideas around, but the point is they should be labelled accordingly, following the '''truth in advertising'''. For example, see TopOnTypes. Top would like a marketplace of ideas, but not a genuine marketplace but a dysfunctional marketplace. The fact that "best practices" evolve from a marketplace of idea, and that some authorities are '''recognized''' rather (than somebody appointing them) as experts in various domain of expertise is a natural outcome of the marketplace of ideas. But Top's throwing some mud at the issues with some pompous but empty handwaving about Europeans, Americans, Darwin and marketplace, because he wants a marketplace where everybody's 2c are just as good. The reason why we have authorities in ComputerScience (and maybe less so in SoftwareEngineering), just like in all other domains of knowledge, is '''because of the marketplace''' not in spite of it, because what the market needs among other things are '''economies of scale'''. Take any particular issue: say types in programming languages. The arguments on one side and the other have been beaten to death and beyond and a core of recognized knowledge and a core of recognized experts have evolved. We don't need every student in CS and every software engineer to re-hash the whole evolution of ideas and re-analyze all the arguments on one side versus the other - that would be a waste of time and '''uneconomical''', and because of that, such an attitude would fail in the marketplace. So we get these recognized experts in PL design, that may have differences of opinions on subtle issues, but agree to a core. And those professors write textbooks that are used in PL courses at major universities, their theories influence (either directly or indirectly) the design of major commercial languages, and that's it. If anybody has very different ideas about how things should be those ideas have to first prove themselves (they have a BurdenOfProof) including in the marketplace. But the fact that we do have authorities and authoritative textbooks, and that to his chagrin ToMind''''''s 2c do not weigh the same as JohnReynolds''''''' published book, well, that is the direct result of market forces at work. -- CostinCozianu * This marketplace is not a very efficient one (in the economic sense). But the main problem with that is that it has delayed introduction of concepts from academic ComputerScience, which doesn't support top's argument either. -- DavidSarahHopwood ''Most of "computer science" has NOT proven itself. It is a very dark grey art, and argument-by-vote and argument-by-authority has proven wrong or questionable many times. Besides, new ideas won't get put forward if we dwell only on the most popular or academically sanctioned ideas. Plus, maybe other theories are a better way to say more or less the same thing. For example, my "Internal flag" type definition is far more approachable than your vague favorite. It may be a UsefulLie the way that Newtonian physics is a UsefulLie even though relatively is technically more accurate. My def only takes about a page while yours takes 200. Long definitions are a smell in ANY discipline. Shorten it before sanctioning it. If you want to provide an "official sanctioned material" view for newbies, make your own damned web-site rather than play Content Dictator here. If you are feel your are that ordained to make a proper presentation of computer science (cough), then make it in your own image at your own domain address. In other words, buy your own chapel to paint your Grand Mural instead of mucking with ours. The web gives you that ability, use it! If you are so dissatisfied with this wiki that you have to wage massive deletion wars, then it seems pretty clear that the only way to get something that makes you happy is to create your own personal wiki shaped the way you want it and keep out alleged riff-raff like me. If it is easy to move, then it is not worth trying to kill all the neighbor's pets. You remind me of the guy who picks fights in bars over his "favorite chair" when the joint in nearly empty. Move on, dude. There's plenty of seats in the Web. -- top'' Novel ideas are welcomed by most honest people. But where there is a body of research or practice in topic, it is incumbent on presenters of new ideas to understand the past, and the vocabulary that developed around it. This informs the effort to develop new ideas, and is considerate of the time of and patience of people reviewing them. Lacking this consideration, it can only be expected that new ideas will be rejected as a practical matter - a matter of ''economics'', in the sense that Costin argues above. Endless Layne's laws arguments benefit nobody. Also, the hallmark of the snake-oil salesman in any field is someone who redefines terminology to suit their purpose, or rejects inconvenient established notions without a solid argument for that rejection - and ''defends'' these actions against all comers vehemently. Someone making honest mistakes for lack of knowledge doesn't have that last characteristic of intransigence. I agree with Costin in that I'm tired of postings that bear these traits, whatever the motivation behind them. They clutter the wiki. I've made more than a few gaffes of my own on this wiki, and learned things along the way - usually in the form of pointers to places where I could get more specific information ''through my own efforts''. I've also offered advice and pointers to people where I was able. I've had some interesting exchanges with TopMind, but by and large the exchanges are no longer worth the effort, because TopMind not only ''is'' lacking background in the fields he's dabbling in, but also insists that acquiring such is counter-productive. Although this may be true for him personally, he should note that this anti-intellectual stance makes his own contributions much less valuable to most people on this wiki - and even misinforming to less knowledgeable readers. -- DanMuller I replied to the above while it was being re-edited, so here is the version I replied to: Novel ideas are welcomed by most honest people. But where there is a body of research or practice in topic, it is incumbent on presenters of new ideas to understand the past, and the vocabulary that developed around it. This informs the effort to develop new ideas, and is considerate of the time of and patience of people reviewing them. Lacking this consideration, it can only be expected that new ideas will be rejected as a practical matter - a matter of ''economics'', in the sense that Costin argues above. ''Then mark the official ones as official and let the rest live on the bottom of the page. Demoting and killing are two different things. Or, come up with a naming convention for the alternative opinions so those who want the "official" view know to ignore the non-official ones. In the cyber age we don't need to have only one opinion/view anymore. Stop thinking in the 70's.'' Endless Layne's laws arguments benefit nobody. ''I generally avoid definitional issues and instead focus on output. However, it cannot not be avoided in some cases. The only definition I really battle over is "types" because the one proposed by Costin is useless in practice to most readers. I asked him to clarify "rules" and he ignored it. If he does not want to defend his pet definition, then don't complain when alternatives are offered.'' Also, the hallmark of the snake-oil salesman in any field is someone who redefines terminology to suit their purpose, or rejects inconvenient established notions without a solid argument for that rejection - and ''defends'' these actions against all comers vehemently. ''I have given plenty of valid reasons for rejecting Costin's "types": Too long, too vague, and requires a BookStop because he is a poor paraphraser. It is ugly. A definition that requires 200 pages is just plain fscked. '''There's nothing comparable that is useful'''.'' * Top, when do you ever consider that a BookStop might be useful to you? Do you believe that all CS books are evil, and all valuable knowledge can be picked up from chatting on the internet? * ''Most CS books are, "here are some axioms, and here are a bunch of techniques that can come about with these axioms." Axioms usually are, or should be small, but the techniques based on them can run on and on. That alone does not make the axioms "right", just better explored. Given enough time and money, I too could write thick textbooks on my "flag-based" type theory by exploring it from a bajillion angles.'' * Top, that's another claim by way of handwaving. Where's the SelfStandingEvidence to support it? How can you be able to appreciate how "most CS books are" when you don't seem like you read much of them? Never mind, please '''answer the question''' as it was formulated: when do you - if ever - consider that a BookStop might be useful? * ''No, it is an informal survey. How would you characterize them? I would bet money that the types book would be just what I describe.'' ** BS informal survey. You pulled that out of your ass and pretend you have an argument. Argument by throwing mud. Because wiki space is free and any wannabe can say anything about any subject, right? Where's your '''objective evidence''', Top, if you have any, that most CS books are as you say? Commonly, you complain about others not presenting evidence, and you pull all kinds idiocies out of your ass for which you refuse to be held accountable. Get lost, buffoon. ** ''It is an "informal survey", it is NOT BS. I once had a contract for a university and used to browse the textbooks during my lunchbreak. Even Chris Date's textbook is that way.'' ** More BS top. You once had a contract for university and browsed books during lunchbreak. That's a nice culturalization effort on CS matters, during lunch breaks. Didn't they give you a master's degree for the effort? How is that SelfStandingEvidence top? Are we supposed to believe you that you had some lunchbreaks and you were in a position to make an informed opinion on the quality of CS books overall. Spear yourself the embarrassment and quit arguing every point to ridiculous levels. ** ''I didn't mean to imply that was my only exposure. It is not objective proof and was not meant to be. It is anecdotal, just like your counter evidence. '''The default is null''', not your side of the argument. They generally follow the same pattern: about 10% definition or axioms, and 90% "techniques" on those axioms. If this is wrong, then what *is* the mix from your observations? I can't get strait versions of your side of the story.'' ** No, TOP the default is not null. Weren't you the one complaining that the CS professors are paid to write textbooks while you aren't? That means the default is null only in your own eyes. You have always had a high regard for your own person and your own ideas and a high disregard for anything else. But out there in the reality outside your brain the scale of values is exactly the opposite of what you think. You won't get my side of the stories because I don't feel compelled to respond to trolls. When you'll be able to put an honest argument forward, I'll respond to you. ShiftingTheBurdenOfProof is dishonest trolling not something that should be responded to. ** ''Argument-by-published-paper-volume. Classic elitist horse drip. Just plain classic. Why not just prove your claims in place instead of hiding behind textbooks that nobody reads? And, why are you afraid to give an estimated "mix" ratio value?'' ** I don't "prove" because I'm not willing to discharge you from the BurdenOfProof, and don't want to feed the trolls. ** By the way, Top, how about you start proving something like that the Earth is round and moving round the Sun on an elliptical curve. You surely know that, but how about proving it? SelfStandingEvidence, please, no BS. Don't make reference to astronomical observations cause that will mean referring to other people's work, ArgumentFromAuthority, and by the way, in order to understand your proof, the poor reader will have to execute a full BookStop and read up on basic astronomy, oh no, we don't want that. Reading books is bad. Books are written by a cabal of those academia types no good. Say Joe Shmuck wants to claim that the Earth is flat and the Sun moves around the Earth in a perfectly rectangular trajectory. And you want to claim that the Earth if round and moving around the Sun. If Joe Schmuck provides no SelfStandingEvidence and you provide no SelfStandingEvidence either, let's call that, how do you call it, " the default is null". Both of these theories should be equally welcome to wiki and let's declare the battle a draw. because we don't want to abdicate from the noble principles of SelfStandingEvidence and we don't want an ArgumentFromAuthority, nor do we want BookStops, because books are bad, aren't they? Oh, didn't you know TopMind? Just like ComputerScience, Astronomy is bankrupt, their books are no good. So how about you Top, give us a fine demonstration of SelfStanding evidence and prove to us that the Earth is round, so that we can sleep well tonight? ** It is you that need to prove the idiocies that you claim. Just like if Joe Schmuck wants to claim that the Earth is flat, '''nobody''' on wiki would have an obligation to prove the opposite to to Joe Schmuck according to the troll minded rules of SelfStandingEvidence. * And I don't provide "mix ratio values" because I don't feel compelled to respond to ill-posed and irrelevant questions. Give up trolling first , then you can have a conversation. * And by the way, you just produced objective evidence right there. You too could write thick textbooks if given enough money to support your ramblings. But the fact is: nobody gives you that money. That's an objective fact, and should be used as evidence for the purpose of this discussion (undoubtedly you'll find all kinds of explanation for it, but it '''is''' evidence). * ''Argument-by-popularity again. DrCodd had a hard time convincing people at first also. IBM ignored him until other companies started using it. Besides, I simply proposed the idea as something to ponder, not a Nobel submission. '''I wish somebody gave me the "flag" metaphor when I was younger'''. It is very useful, even if it by chance turns out not to be perfect. Like I said, it just may be the Newtonian version of types to the quantum-mechanics-like one you are so fond of. I would appreciate if you give more evidence that it is not a UsefulLie before edit-locking it. (I suspect the other one is also a lie).'' * Top, don't get ridiculous, here. First of all, DrCodd was a doctor, not an ignoramus; second, they did pay DrCodd to write books, articles, and more than that, and it gets so boring that suffices to say this: any comparison between your situation and DrCodd is a sure sign of trouble. As to your "flag metaphor", tell me what happened, Top, have all your worshippers died, so you were left to praise yourself? * ''You guys are too damned dependent of ArgumentFromAuthority. I believe in SelfStandingArguments. If you don't, then we are forever locked in a philosophical HolyWar, and probably EditWar. -- top'' ** What SelfStandingEvidence TOP? SelfStandingEvidence it's not a principle but the troll device you are using. As a proof of that, you fail to provide '''any''' SelfStandingEvidence for the BS you spread here. ** ''You meant the textbook thing? The default is null. See above.'' Someone making honest mistakes for lack of knowledge doesn't have that last characteristic of intransigence. I agree with Costin in that I'm tired of postings that bear these traits, whatever the motivation behind them. They clutter the wiki. I've made more than a few gaffes of my own on this wiki, and learned things along the way - usually in the form of pointers to places where I could get more specific information ''through my own efforts''. I've also offered advice and pointers to people where I was able. I've had some interesting exchanges with TopMind, but by and large the exchanges are no longer worth the effort, because TopMind not only ''is'' lacking background in the fields he's dabbling in, but also insists that acquiring such is counter-productive. Although this may be true for him personally, he should note that this anti-intellectual stance makes his own contributions relatively valueless to most people on this wiki - and even misinforming to less knowledgeable readers. -- DanMuller ''In my book, fighting against SelfStandingEvidence is "anti-intellectual". I think it is clear from ObjectiveEvidenceAgainstTopDiscussion that I don't go around making objectively "wrong" statements for the most part. I trip sometimes, but so does anybody.'' ''Come up with a clear-cut definition for "types" that takes up less than 3 pages and I will delete mine, deal? -- top'' ''A definition that requires 200 pages is just plain fscked.'' - Another typical argument of the snake-oil salesman, without any support. A topic takes as much as it takes, and a more rigorous treatment will take longer than an intuitive, vague one. ''Too long, too vague, and requires a BookStop because he is a poor paraphraser.'' This "BookStop" crap is what got my goat recently. From this stems my accusation of anti-intellectualism - although more likely, given the evidence, it's just an excuse for laziness. Or it's just more evidence of the ScienceShouldBeEasy fallacy, which is another hallmark of the charlatan. '' * Can I list hallmarks of elitist pricks in response? * ''Sure, if you wish to descend to that level. Note that I've not called you a charlatan; I've simply pointed out that your techniques are reminiscent of those used by such. Take a look at "pyramid power" promoters and their ilk, as an example. If you're comfortable with those attitudes, by all means hold them dear. But realize the company that you're keeping, and the reactions such behavior will evoke. -- DanM'' * The pyramid power claimers often say, "Go buy and read my book and you will see evidence for how useful the power is." * ''Yes, so both legitimate and illegitimate scientists have in common the ability to write books and refer to them. And your point is? -- DanM'' ''Any given type system can be simple; types as a general topic in computer science is not a simple topic, as can be seen by examining the many different treatments and applications of the topic in both the literature and in language implementations. To say that you've come up with a simple type system says nothing about the topic of types itself, and you cannot argue the merit of your simple system vis-a-vis other type systems without understanding the more difficult general topic. Even I, who have a lot more to learn about formal type systems, can recognize this. Besides, I don't particularly care about the type debate myself - it's not something I've bothered following for many weeks - so one of your infamous "challenges" is of no interest to me. ''I generally avoid definitional issues and instead focus on output. However, it cannot not [sic] be avoided in some cases. The only definition I really battle over is "types" ...'' -- How about closures, as another example? You don't argue about the definition thereof, but you debated their merits for weeks with copious volume, then display a ''utter'' lack of understanding about what they are on that same page. Having participated in this discussion felt like an utter waste of time, since you obviously didn't understand the definitions of things being discussed, and hadn't corrected that lack over the course of the entire discussion. A "focus on output" is useless unless you can describe your output in terms other people can understand. And the value of your output is proportional to your understanding of the problems that have already been identified by the field of research, and the solutions that have been put forward. You don't even understand concepts that you are debating! * ''The closure issue became a focus when somebody claimed "significant code reduction". I grabbed onto that because it is not a matter of interpretation or vague "elegance" claim, but of seeing less code. I made that clear early in the debate in bold letters.'' * Yes, and it was also made clear on that page that closures do use less code for common tasks (tasks that others find common, anyway) than kludgy techniques using uplevel references. The preferability of full closure support was even admitted by a TCL programmer that you recruited to the debate. And yet - and yet - you continued arguing about the adequacy of simpler techniques while displaying an ignorance of what you were arguing ''against''. Incroyable. * ''"Kludgy" does not necessarily mean more code. And you even admitted above that they were simpler, which should be a point for them. Note that I did not see any full example that was shorter than about 5%. If it was there, I missed it.'' * Simpler to implement, not to use. Anything that reduces bookkeeping overhead in my head is valuable, whether it reduces code size by 0% or 50%. And closures do exactly that. Code size is not the only useful criteria for language features. It's not even clear how "code size" is best measured. Tokens? Characters? Lines? Expressions? Statements? Conceptual units? -- DanM The endless calls for examples is tedious. The examples provided on various topics haven't impressed you; that may be appropriate, since they may not address fields of programming that concern you. So you need to understand the concepts people are talking about so you can ''try for yourself'' whether or not they apply to your concerns. You don't do that - you simply pronounce that they don't, without anything more than a fleeting notion of what the concepts are. And before you go off with "but you function weenies said that your paradigm makes smaller code" rejoinder, let me point out that I, personally, never made that claim, don't think that such a claim can be made meaningfully without excessive qualification, don't consider myself a functional weenie, and have always offered only suggestions for things that I thought you might find to be helpful, interesting, or informative in your pursuits. * Then don't get on me for putting their claims to the test. Get on THEM for making such stupid claims. * In the particular case of closures, they were right. I did not participate on the other pages on which broader claims about functional programming, since I had no immediate interest in them. I use a functional style of programming when I can in order to make my code more easily understood, not to reduce code size (although it sometimes has that effect in C++).-- DanM * Are you saying their closure examples were more than 5 or 10 percent smaller? * I don't know, I didn't measure them. See above. -- DanM I never intended to get embroiled in "my paradigm is better" debates, but found myself inexplicably defending, at length, against ''uninformed'' objections. Very annoying, rarely edifying for me in any way, and apparently not for you either. Pardon my rant, but between the edit wars and the sheer volume of Top-generated lightweight content, I've gotten quite frustrated with C2. This should perhaps be moved off this page, since we're cluttering yet another one, which was actually (yet another) meta-discussion on wiki content. ''When you saw that silly "significantly less code" claim, you should have stopped it. Besides, if you don't like a topic, then don't read it.'' * See above. When I saw the phrase "significantly less code", it was usually you repeating it. And note that I like the topic of closures - and many of the other pages that now consist predominantly of arguments between you and others on very basic issues. -- DanM -- DanMuller And another thought while I'm on a roll: Your stereotype of Europeans is one that I won't argue against, although I think that it applies only very weakly. A more applicable stereotype, though, is that European schools tend to have more of a focus on rigor, precision, and foundational knowledge than American schools do. Your style of example-based debating will seem patently absurd to someone with this kind of background - it's not a matter of rejecting your ideas because they lack the backing of an authority, it's a matter of rejecting them because they lack rigor, precision, detail. You'd do well to learn from their arguments rather than belittle them. To sum up much of the above, you should perhaps allocate a little more time for ''input'' versus ''output''. -- DanMuller Examples road-test stuff much better than "elegance" or MentalMasturbation. (The ideal is production systems, but those are usually not practical here.) -- top And here is where we differ fundamentally. If you're going to lament the state of computer science, realize that its primary problem is a ''lack'' of application of theory and thorough reasoning. An example is never a replacement for understanding, it's an adjunct to it, a helper. If the only way to "prove" something is to produce a production system that illustrates it, then computer science is doomed to decades of trial and error to achieve every small step forward. And that's exactly what we're seeing lately in computer science, after much bigger strides were taken almost two decades ago on the basis of careful reasoning about computing. -- DanMuller The low-hanging fruit has already been picked, and it appears one has to crawl through psychology to get to the next level. The first few decades focused on performance and implementation. Now that those factors are shrinking from view, what we see left behind is a mirror of ourselves. (Wow, I'm a geek poet :-) And, has it occurred to you that many others might not wiki to be nothing but BookStop''''''s either? Why learn quantum physics when Newton will do for 99% of all readers? -- top The low hanging fruit hasn't yet been picked, we have legions of uneducated programmers like you who still have jobs. You are the low hanging fruit, you are ignorant and totally unaware of it, and you pollute this wiki, almost to the point of making it worthless anymore. Seems like edit wars and topmind will be the death of wiki. If you actually read all those pages that you claim victory on, you'd realize you've lost every argument you've been in from every point of view but your own. I do hope Costin continues harassing you, you deserve everything he can throw at you for the damage you've done to this place. Bad ideas should not be kept, because disinformation, that's what it really is, is damaging and leads to making it near impossible to find accurate information. 90% of your content should rightfully be deleted as garbage. -- AnonymousDonor Agreed, and to which I add that it's a pity. I saw Top's pages on TOP long before he came to wiki, was sympathetic to his opinions regarding OOP, and was intrigued and somewhat pleased when he came to C2. TOP is an interesting point of view that has merit. Sad that Top ended up being a source of nearly boundless, obscuring dross on most of the topics that interest me here. Top, every idea, whether good or bad, gets attacked here. Learn when to defend, when to ignore, when to listen, learn, and concede mistakes. But please don't fill the entire wiki with knee-jerk, desperate, at-all-costs defenses. Every topic you have commented on, or question you have brought up is a, worthy one - and every one could be discussed in a tenth of the verbiage if you would use terminology the way others do, take the time to educate yourself on things you want to discuss, and have the grace to not argue points for which you don't have and refuse to acquire the requisite knowledge. ''"Why learn quantum physics when Newton will do for 99% of all readers?"'' Nobody is discussing all readers, we're discussing ''your'' content contributions -- which, to continue your analogy, consist to a large degree of ''misleading'', ''confusing'', and sometimes ''incorrect'' explanations of why quantum physics is unnecessary for designing nuclear reactors, and anyone who tells reactor designers that they need to learn quantum physics is part of the failed and dysfunctional physics establishment. Because you're involved in arguments related to language design, you need to understand issues related to language design. There is plenty here (and even more elsewhere) for people who want to discuss less involved topics - on appropriate pages, and not masquerading as computer science. -- DanM I find the nuke reactor analogy flawed on many levels. For one, such reactors cannot be built with Newton alone. Nobody has shown outright failure of my suggested alternatives. Second, use the right tool for the job. If "eval" will kill somebody, then use HOF instead. I don't dispute that. If I was writing a hospital life-support system, I would probably use very different tools. -- top ---- To end this going round in circles, about FP and SelfStandingEvidence and code size reduction: FP languages and techniques (including closures but not only) was claimed to offer advantages, including code size reduction - but '''not only''', but nobody ever claimed that this applies to all problems in all domains (such a feat is ridiculous to be claimed for '''any''' approach), but it was specifically said that FP is a good approach for '''algorithmically complex problems'''. ''That domain-specific defense came too late in the game from the FP'ers.'' As a way of SelfStandingEvidence Top was directed to try to solve the relatively challenging exercise described in EnumeratingRegularLanguages, but he refused to do so in his own style. So whenever he's presented he refuses to consider the evidence. Should he try to solve that with his FoxPro favorite and compare to a Haskell solution, he'd get what everybody means when talking about the advantages of FunctionalProgramming. -- CostinCozianu {My challenge was first (#6). And, why do you complain when I reject their challenge but not when they reject mine? The referees seem biased.} * You challenge was '''irrelevant''', and doesn't matter whether it was first or the 1000th. If you really wanted to find out the benefits of FP (rather than trolling according to ArgumentAdPerpetuum), you'd have to examine the evidence that is presented to you by those who know something about FP and what it is suited best for. That has been presented to you, but you cannot be bothered either to learn new things or to be a bit more humble about the crappy claims that you make. Your argumentation on this one translates to this: ** Michael Jordan was a great athlete ** Bullshit, I know he was lousy. Look how unimportant he was in baseball. ** Can you look at how he played basketball? ** No, '''my example was first'''. Your reply came too late, I won the point, look guys how smart I am:0 * ''That Jordan example does not make sense. Is there a typo in it?'' This is the kind of silliness you bring to wiki. We're tired of it. Of course, anybody at all can bring an ArgumentAdPerpetuum, that is you'll argue endlessly clutching at straws trying to get the last word no matter how irrelevant. You can even claim victory if that makes you feel good or victorious. However, the arguments that will be found irrelevant and trolling will be '''moved aside'''. EvenbadIdeasShouldBeKept, but they need not clutter good content. End of the story. [ No doubt he will jump in again, and claim that the exercise described is not a "practical" problem. Which is more BS. Practical problems have some hurdles to present in public, including their excessive complexity both in solving them and in presentation -- sometimes the complex algorithmical problems wiki contributors encounter in their day to day work are just too complex to describe on wiki plus the information may be restricted by employment contracts. However EnumeratingRegularLanguages is an '''useful''' example that many people will find representative for algorithmically complex problems. So it is SelfStandingEvidence, and by all accounts much more '''objective''' than the story about how TOP surveyed CS books during lunch-breaks and arrived to the conclusion that CS is bankrupt ] ''Bookstore issue addressed above.'' ---- There seems to be a pattern to the topics we fight over. My suggestions are far simpler, but still carry a lot of power or utility. Eval (string substitution) is a conceptually simple idea, yet can provide much of the meta ability of closures and HOF's for light use. Same with my "flag" type definition: simple, yet explains and classifies the 3 kinds of type systems that the vast majority of programmers will encounter. '''80% of the power for 10% of the cost. It is a friggin' bargain.''' MY SUGGESTIONS ..Complexity: **** Practicality: *********************** YOUR SUGGESTIONS ..Complexity: *********************** Practicality: ***************************** * Non-sense, you pull those things out of your ass again. Of course composing strings is much more complex for the '''user'''. Of course interpreting strings is much easier for the language implementor than providing HOF and closures but that's complexity incurred '''once''' by the language implementation, and besides that complexity is well managed - the implementation techniques are well known, practiced verified , but the complexity of having to compose strings to be evaluated rather than compose functions and bind argument will be incurred several times by the users together with other bad effects as well. * ''BS. I have used eval many times with little or no problem. You are making up stuff. Maybe the problems only happen when one reinvents CollectionOrientedProgramming from scratch, like FP'ers are fond of doing.'' * No, bullshit to you. I want to write a bit of code to be passed on and executed elsewhere or elsewhen. What's easier - writing a bit of code, just like I usually do, or writing a bit of code as if it were a string, and then remembering whether I have to use up-references or not, etc.? Get real, Top, what frigging planet are you living on? -- DanM * ''Sorry, but such has never been problem for me. I am sorry if it trips you in particular. I guess we all have flaws in different areas. Plus stringing ''(Ouch! He verbed a noun! That hurts!)'' has the advantage that I can store it in a database, a floppy, send it over the wire, etc.'' * Nobody said that using strings was "a problem" for anyone. How can you argue with the statement I made immediately above, which basically boils down to: "To get code, it's easier to write code than to write something else?" What an idiot. As to your other "point", it has already been countered (by someone else) on DynamicStringsVsFunctional, so I won't take the bait to walk around another circle with you. -- DanM It is as if we found that Uncle Joe's amateur photography skills are good enough to use for the wedding pictures and so we don't need to pay a professional photographer $8,000. You sound like the professional photographer griping about subtle color balance and other shit that most people either don't even notice or don't want to pay triple the rate for. Businesses have indicated in several ways that they want PlugCompatibleInterchangeableEngineers (for good or bad). Finding simple solutions to complex needs goes a long way toward that. The vast majority are not going to read the "official" types book, you know that, I know that, and putting closures in languages tends to kill them in the market place. I am only responding to the market, but catching flack from the defensive elitists in the process who seem afraid that populist and amateur movements are going to devalue their hard-won knowledge. Buck up, and move with the times instead of fighting it. -- top What you always miss, because of your lack of education, is that the proposed solutions you fight against are almost always vastly superior, and vastly simpler than yours. Strings are not the simple solution, they are the complex solution. Your ideas are usually overly complex, overly verbose, and seriously repetitive, quite simply, your code usually sucks. UnskilledAndUnawareOfIt as usual. You really don't know what "simple" actually means. ''Claims claims claims claims. But no show. If you are so goddam full of knowledge, then use it to show code that tap dances and washes windows, etc.'' To whom, an incompetent programmer who's shown time and time again that he can't grok code examples at all... yea right. ''"Overly verbose" and "seriously repetative" should be '''easy to spot'''. You guys had 3 chances to demonstrate similar claims that would be easy spot:'' * HowCanSomethingBeSuperGreatWithoutProducingExternalEvidence * ArrayDeletionExample * ChallengeSixVersusFpDiscussion EnumeratingRegularLanguages, Top, remember? ArrayDeletionExample doesn't prove much - what can you expect from trivial examples? ChallengeSixVersusFp is irrelevant, plus your code the is full of holes anyways, but it's irrelevant. You want to be convinced even more? Pay a visit to IcfpProgrammingContest, you'll find plenty. It's embarrassing for you to lie again and again and again that nothing has been presented to you. You won't accept anything that doesn't prove your point because you're in the troll position.Yeah, using strings instead of closures is the complex solution, it also can be full of holes just like your code on ChallengeSixVersusFp is. ''I have agreed many times that FP may be good at certain domains. But you did not qualify which domain your claims belong to. This implies they are not domain-limited, right? I want to see how it does in my domain, not systems software and programming contests. I've found contest examples impractical anyhow. Why should people listen to your FP braggings if you only present narrow examples that have nothing to do with their domain? Why is everybody afraid of #6?'' Enough with the page-filling metaphors already - you produce another one for every three paragraphs you write. ''"The vast majority are not going to read the "official" types book..."'' '''OF COURSE''' that's true. Stop trying to hide behind "the majority" or "99% of readers". We're talking about people purporting to DESIGN languages, not USE them. If the language gets things right, explaining how to use it is easy. If it gets them wrong, and there are numerous ways to do that, users of a language get hit with surprises, or drudgery, or plain lack of ability to do some things. The ''language designer'' has to do the hard work so that the ''users of the language'' don't have to. And lo and behold, much of that hard work has even been done for him already! It's all written up in the level of details needed by the language designer - in books! My god! Here's a metaphor for you: How much do you need to know about combustion engine design to drive a car? Would you be happy with your car if the guys who designed it knew only as much about the topic as you do? * If you are targeting only language writers, then maybe make a separate topic for them. Further, my approach can reduce type-checking to old-fashioned tree traversal, as described in [forgot link will insert]. Further, Costin's assertion that languages that ignored "type theory" had flaws because of it appears weak. See LanguageTypeErrors. ''"... putting closures in languages tends to kill them in the market place."'' - What on earth???? No, what kills good languages is ignorance and lousy education - copiously documented. You should be pleased, many universities are actually in your camp these days, eschewing theory in favor of hands on tinkering and "trade skills". And open source activity is dominated by tinkerers, too. That is the bankruptcy of software engineering these days. * Re: "You should be pleased, many universities are actually in your camp these days", well if that is the case, then your assertation that I should be deleted because my approaches are a "minority" falters. This appears to be a larger educational institution culture war rather than me being "wrong". ''"... afraid that populist and amateur movements are going to devalue their hard-won knowledge."'' - No, I'm afraid that I'm going to get stuck in job after job maintaining or fixing code produced in bad languages by lazy programmers, or using their products to try to do my own work. This trend is already well under way, and it's absurd given that ''we already know how to do these things better''. * The trend is to offshore all that. 5 amatures slogging through bad code may still be more cost effective than hiring a hyper-educated expert. That is the way managers seem to want it anyhow, for good or bad. I have found that making people happy is better for one's career than fighting to do it "right" anyhow. See WarStories. If you want to sell ideas such as HOF to a wider audience, you really need to find some "killer" examples in domains more people can relate to. -- DanMuller ---- It might be said that just as beauty is in the eye of the beholder, that ugliness is as well. Ideas are formed in the mind of the one who states them, however imperfect, they exist in that one context as something worth stating. Ideas in a mind which are not exposed are except for that one mind, non-existent. Ideas which have been accepted by one and then shared by many can be said to have proliferated. The more widely available the idea is, the more value it has, whether it be bad or good. Ideas that have not been shared, exposed and given their time in the sun, however good or bad they may be, about them this page says: EvenBadIdeasShouldBeKept. If the are shared, exposed, accepted or rejected, they can by being exposed, be said to be ideas which have been tried. In the spirit of OnceAndOnlyOnce, should it be necessary to have some one rediscover a bad idea because it has been removed from visibility? Even failed experiments teach us something. See ThomasEdison. -- DonaldNoyes Look at it this way: if you don't find better reasons and clear-cut rules to ban or delete alleged trolls, then you will keep having the same trial over and over. -- top ---- A good many music pieces from the Baroque era have been '''forever lost''' because those of the following generation considered it "too primitive", not understanding the perspective that time gives. There are likely some amazing works out there. Works like Pachelbel's Canon were tossed as garbage, only by shear luck to be found again. There's reason to believe that many of his other works are lost. And then there's folk music of various times. Because it was "low class", very few were documented. *''Many book authors and song writers have learned to keep all as well, as sometimes that misfit is the capstone that finishes a current work. I can see the same applied to programming, where an idea that did not fit its original purpose, becomes that magic that fits another, or fuels the thought that leads to completion.'' * The hard part is keeping track of it all. If we by chance become as famous as Beethoven, then somebody else may bother organizing it after we belly-up. But otherwise, it will stay a big wod of string unless we organize and/or index it ourselves. ---- '''Notes:''' 1. Bad ideas that have led to bad results need to be isolated in a TheRoadNotTraveled collection of some kind, not hung on to the mainline thinking like an anchor. We don't need bad ideas and mistakes dragging us down. ** But what if somebody comes along searching for such? Say they wake up one day with the idea of writing a Web Content Management System in Fortran, and want to see if anybody else has tried it or thought about it? They are not going to know to search in TheRoadNotTraveled or the like. Plus, the flexibility of cross-referencing is gone when they are all lumped together. This wiki's referencing system doesn't do well below the page-level granularity. Related: WikiFilterist. ---- ''Given enough time and money, I too could write thick textbooks on my "flag-based" type theory by exploring it from a bajillion angles.'' - But you didn't, you currently don't, and most likely you never will. There is a significant difference between your ideas and the lost Baroque music pieces. The music pieces were finished works, ready for performance. You are still in the state of vague ideas about new paradigms that maybe could be used for composing some kind of rhythmic sound. Where is the formal definition of the language that is based on Table Oriented Programming and tag-based types? Where is the toy prototype interpreter implementing this language, that we could download and use to play around to seriously evaluate your ideas? After all these years, you have achieved '''absolutely nothing''', only megabytes of fruitless discussions in a Wiki that you seem to mistake as your personal homepage. You don't want to write a book when you aren't paid for it? No one will write your language for you, based on all this vagueness, when you don't pay him for it. I can only speak for myself, but I don't care about your promises of a never-felt-before musical experience, when the composition would only be based on your ideas. Let us feel some live audio snippets. Prove that your ideas are worth to care about them. Ideas are worthless until implemented and used. -- AnotherReader TableOrientedProgramming is a technique, not a language. True, a language/tool-set could facilitate it. I've seen other programmers use TOP in ExBase before I even met them because it made tablin' so easy (although stunk in other ways), lacking the "big-iron bloat" of most RDBMS and having a tight-knit relationship between imperative language and tables. And see TopsTagModelTwo for more specifics on the tag model. And Leonardo Da Vinci floated a lot of useful ideas even though he rarely "finished" them. I'm not saying my creativity is comparable to Leo's, but it shows that lack of full implementation is not necessary to spark ideas. It helps, sure, but is not a necessary requirement. You seem to be using the '''perfection-or-nothing fallacy'''. --top ''My def only takes about a page while yours takes 200. Long definitions are a smell in ANY discipline.'' - ''A definition that requires 200 pages is just plain fscked.'' - Maybe you took your own advice from far above too much to heart. Was the Wikipedia article about Leonardo too long for you to read? Did you play with "Leo" together as childs in the sandbox to know that much about him and his "rarely "finished"" ideas? I don't even know what name to throw at someone who as much as hints at comparing himself to this man. Well, let's be fair and take a step back. How many of your ideas presented here are so far and completely specified that they '''could''' be brought to a practical implementation by someone not you? And no, the "more specifics" is a page full of example pseudocode. I couldn't find any useful specifications on it, and neither on any of the other pages about your tag model. To go back to the lost music: Is there '''any''' music sheet from you, finished or not, perfect or not, complete or not, that could immediately be performed by an orchestra? -- AnotherReader Every language is different. It's only a "kit" for building language-specific models, not actual models. And it's better than your obtuse garbage of a model. Yours is not runnable as-is either, Mr. Glasshouse. And your breath stinks. [That's funny, some of the stuff you are claiming isn't "runnable" has been in use for hundreds of years.] You compiled George Washinton's wooden teeth? As it is, it's neither runnable nor clear. These were my first posts after lurking here for quite some time, so you don't know who I am, I don't know what "obtuse garbage of a model" you're talking about, and I brush my non-wooden teeth at least two times a day. If you take it that literal and don't get the metaphors, then yes, Leonardo rarely finished anything. The Mona Lisa isn't compilable or runnable as well, so it doesn't count. I take your answer as affirmative that there really is nothing, so I will fall back into read-only mode and continue to not care about your stuff. Enough of your valuable creativity time wasted in yet another fruitless discussion. You have models to build, inventions to make and worlds to change. Never mind the proper specifications to write - the lost Baroque music may have been properly written down to music sheets, but it obviously wasn't distributed enough. The Wikipedia page for Leonardo would not even exist if he hadn't written all his inventions down, even though he mostly kept it to himself. And who knows if this world would be a better or a worse place if the Bible, the Koran, the Talmud, and whatever else, were never properly written down at some point in history and distributed to everywhere. Distributed or not, it was all properly written down. That's much more than could ever be said about your "work". -- AnotherReader I still believe you are making the perfection-or-nothing fallacy and the above doesn't address that issue and focuses instead on my (alleged) personality or past gripes. The link I gave with pseudo-code is good enough for many to get started on their own tag models of their target language(s). And one doesn't necessarily have to physically run the model to get use of it; they can "run it in their head". The key concepts are relatively small and simple and the rest mostly just accessor-oriented formalism and data house-keeping. '''If YOU don't like it, fine. But LetTheReaderDecide if they like it themselves.''' -t Related to the Leonardo analogy, a more pertinent and less "gripey" question may be "'''should draft ideas be kept'''"? Being unfinished or "rough" does not by itself make something "bad" or of no value. My point of view is that if somebody may be able to find some use of it, now or someday, then leave it. They may be able to figure it out (if incoherent to most), use it for something after local refinement, or it may spark new ideas. If it's so incoherent as to be likely useless to ''anybody'', then ask the author to bring it up to a minimum quality standard by asking in a diplomatic way to improve it. Ask questions about it, for example: "What do you mean by 'transitive fixture'? Can I see an example?" If you yourself don't make a reasonable attempt to improve it by asking (polite) questions in order to clarify a draft, then you don't deserve the right to delete it also, in my opinion. Give ideas a reasonable shot at life. If you care enough to delete, then you should care enough to try to improve it first. There's a lot stuff on this wiki I'd personally like to delete, but realize I am not the king, and it may be fixable in ways I can't anticipate. -t Okay, I got it now. Let me condense your type tag "model" to one single sentence, so that any language designer and implementer worth his or her salt will immediately know what to do: '''For a given programming language with accessible units of any kind (variables, functions, objects, ...), keep an additional value with each unit that encodes the specific type of this unit, and make this type encoding accessible, to accordingly adapt the operations on the units.''' There we go. I even have a significant improvement. Why reduce the accessibility to the language implementation? Why not provide it to the user who will write applications in this language? Imagine the powerful possibilities that a .getType() will provide. Whoa. You know what? I will blatantly steal this from you and publish it in a thick book as 's Type Query Model (TQM). You don't read thick theoretical books, so you will never find out, even when I'm already rich and famous. Just keep sitting here more years over years and write more and more pages full of fluff without ever getting to the gist. Thank you and goodbye, loser. -- AnotherReader I described it in similar terms before, but was told that wasn't specific or clear enough, and thus eventually fleshed it out in pseudo-code after multiple failed attempts at using mostly English. Being clear to person A does not guarantee clarity to person B. I'm glad it's clear to you, though, after all the complaints by others about the presentation. You are welcome to steal the idea and profit off it. I have enough money. As far as the second part of that paragraph, I'm not clear on what you are talking about. But a response to my requested clarification probably belongs under a new section in TopsTagModelTwo rather than here. -t ------------------ '''Suggested Fixes for "Poor" Content:''' * Incoherent or Confusing ** First ask if it's incoherent to everybody or just you? Different people relate to different writing styles. ** Ask questions of the author in order to clarify points. * Wrong ** Being wrong is not a reason for deletion. Likely the author does not agree he or she is wrong. Present your side of the story and LetTheReaderDecide who's argument is better. ** Perhaps your evidence that it's wrong is poorly done. Try refining your argument such that each step or component of your logic is as sound, objective, and clear as possible. Avoid, "well it's obvious to everybody but you". That usually does not convey use-able info, and probably is not using scientific "popularity" survey principles anyhow. ** Don't assume your definition or interpretation of a word or phrase is accurate or universal. Spoken language is often ill-suited for the virtual world and certain abstract concepts, making communication difficult. See LaynesLaw. ** And remember that addressing allegedly wrong ideas documents how it was "debunked" such that if the same question appears later, it has a ready-to-go debunking prepared for it. * Off Topic ** (This one is tricky. Prior solutions failed to work. More on this later.) * Rude ** Rewrite a copy of the page in a non-rude fashion and offer it as an alternative. Leave the original in place, out of courtesy. ---- Moved discussion to TopOnTypes. ------- See also: WikiFilterist ---- JanuaryFourteen