Even Bad Ideas Should Be Kept
Even Bad Ideas Should Be KeptSomebody recently repeatedly deleted some definition summaries of "types" at WhatAreTypes believing them to be fundamentally flawed.
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 WikiPages 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
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.
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. ''
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!
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.
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.
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 BookStops 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.}
[ 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: *****************************
-- 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:
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?
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.
Notes:
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 <Unit>.getType() will provide. Whoa. You know what? I will blatantly steal this from you and publish it in a thick book as <MyRealName?>'s Type Query Model (<MyInitials?>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:
Moved discussion to TopOnTypes.
See also: WikiFilterist
EditText of this page
(last edited November 9, 2014)
or FindPage with title or text search