[This is a heated debate about the uses of rudeness. The heat was started by the words 'general' and 'simply' in one sentence. You may check the links at the bottom for more balanced accounts.]
EditHint: The intro above is unclear or referring to details that don't belong in intros. Please adjust it or remove it. Thank You.
In general, rudeness simply doesn't work. It does not "fix" people. I've seen rudeness make the problem worse far more often than helping the situation. I don't have any OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy to show this, but my observation and various books I've read on the subject have born this out. (I'm still rude sometimes, but I accept it merely as a personal catharsis, not a solution to the problem itself.)
Those who want to make a case that it does work are welcome to present it. Sometimes it will work once or twice, but it's a weapon that loses its strength on each usage. Used sparingly and with proper timing, it can help; but it's not something to rely on as your primary persuasion tool and has longer-term consequences. (There perhaps are individuals who enjoy abuse overall, but they are the exception.)
The art of persuasion is difficult, especially for us techie types who are often under-socialized by choice or nature. But if you really want to persuade people and change their behavior or outlook[1], you have to do it the careful, patient, and smart way. There's no shortcuts. I'm just the messenger.
Further, rudeness is overused on the web such that if it had any impact if used sparingly, it's rendered moot by the excess one finds on the web. Wolf has been called repeatedly.
[1] You may end up changing our own as an unintended consequence.
- top
[Please note that to have top create such an argument boggles the minds of those who understand the concepts of "irony" and "hypocrisy." Apparently topper does not. Sorry, man, but that's how it is, eh?]
I believe you missed the statement above: "I'm still rude sometimes, but I accept it merely as a personal catharsis, not a solution to the problem itself." The topic is in response to the suggestion that rudeness fixes people and thus it's justified as a common teaching technique. Yes, I am rude sometimes, but do not claim or expect it to change other people's behavior or mind. Thus, there's no irony.
I've rarely seen rudeness applied as a 'persuasion' tactic. Complaining about rudeness on the basis that it doesn't work as a persuasion tactic strikes me as similar to complaining about bricks on the basis they can't fly under their own power.
If you are saying that there are many reasons to be blunt, then I agree. This topic mostly addresses the case where rudeness is used as some form of persuasion or behavioral "fix" incentive.
Anyhow, this whole 'art of persuasion' issue always bumps into ethical dilemmas. Lies, sophistry, and fallacy often do "work" as persuasive tactics, especially when expressed with passion, or when convincing oneself (humans are far too prone towards confirmation bias). Should one measure the quality of an argument by how persuasive it is (how well it "works"), rather than by how reasonable it is?
If one refuses to accept that the ends justify the means in persuasion, then one also might refuse to fight fallacy with the sort of fallacy or illogic that the opposition might grok. This can lead to much frustration, which is often expressed via rudeness.
In many cases, being "right" in a vacuum is of little use, especially if collaboration is required to implement an idea. (Those who are so certain they are right are often not right, but that's another topic. Certaintude for situations with many variables is a smell.) If you are sufficiently satisfied with merely "being right", then there's little use of communicating such on this wiki anyhow, or at least debating.
Being 'right' and being 'reasonable' (in the sense of 'reasoning') are two very different things.
Almost everyone thinks they are reasonable.
Indeed. Many people are UnskilledAndUnawareOfIt when it comes to 'reasoning'. Many people don't even recognize 'reasoning' as a skill or something that can be performed incorrectly.
Reasoning is a skill; one learns to be reasonable the same way one learns any other math, and the foundations for this skill are traditionally taught as part of Geometry, advanced Philosophy courses, discrete mathematics, diagnostics, and many other courses. According to my dictionary, being reasonable means being agreeable with 'sound' judgement, logical, not exceeding the limits of reason - which implies that one can justify inferences without unsound or illogical steps. It has been my observation (as an assistant to an undergrad course in discrete mathematics) that many people have troubles grasping 'reasoning' - even among those aiming to become programmers and engineers.
The widespread incompetence in reasoning isn't too bad for day-to-day stuff - those not skilled at reasoning may be quite skilled at reaching correct and verifiable answers by other means (intuition, search, pattern matching, ExploratoryProgramming, etc.). Reasoning is sometimes overrated in practice; it's really important for BigDesignUpFront (especially when attempting to improve cross-cutting properties of existing systems), but AgileMethodologies don't rely upon it. However, this incompetence really hurts when it comes to technical discussions. People can't 'reasonably' argue from intuitions - that would be a contradiction in terms.
Merely 'thinking' you are reasonable is intuition. Intuition does serve as a good first filter if one has experience in the domain, but any person competent in reasoning knows that the trick is to reconstruct, justify, and (where possible) verify one's inferences, habitually. Reasonable people know they are reasonable, because they can justify it. Reasonable people also know they could be wrong, because they can justify that, too.
The tricky part is when we encounter topics with TooManyVariablesForScience. It would be nice if we could simply apply math, formal logic, and direct scientific experiments to all debates, but because of the variable quantity and funding problem, we can't, or don't know how yet. We have to make assessments based on lots of information, but also with lots of incomplete information.
I usually cut people some slack when dealing wish such issues. I may not agree, but I will respect their opinion if they made a good effort to justify their opinion and counter mine. I don't see that from the other party. They are filled with certaintude about their opinions on variable-heavy topics and accuse the other side of committing formal or objective fallacies. Certaintude in the face of many variables is just plain smelly. - t
Tags like 'HandWaving' also "work" to at least caution others in the potential audience, even if they strike the immediate recipient as rude.
Are the up-sides of warning others more than the down-sides of risking, FlameWar, retaliation, complaints, and ill-will?
That's questionable. Problem is that silence often is implicit approval of the community in the eyes of most audiences. The only thing necessary for the triumph of EvilOrStupid is for good men to do nothing. How does risk of FlameWar weight against offering your implicit approval?
I'm not understanding this. It sounds like you place "being right" over being civilized, and will accept the chaos of war (likely outcome of excessive rudeness) in order to "enforce truth". Is this true?
In the uncivilized wild west, you appeased the guy with the big gun, fast draw, and foul temper. In the uncivilized WikiWiki, TopMind suggests we appease the guy with the big tantrum, fast retaliation, and foul temper. That's hardly respect for being 'civilized'. War is the last refuge of the incompetent. Anyhow, you present a FalseDichotomy: appeasing the stubborn incompetent in order to avoid potential 'retaliation' versus 'accepting war' in order to place education, reasoning, culture, civilized behavior above the complaints of the stubborn incompetent, the sophists, the vociferous ignorami. There are other options - exclusion, temporary bans, behavior correction, tests, juries, administration - civilized mechanisms for resolving conflict. WikiWiki, of course, lacks the technical and social structure to achieve these civilized mechanisms, so I accept it to be an uncivilized place, filled with uncivilized people, and (since nobody dies in the 'wars') I'm willing to accept the occasional tantrum from the stubborn incompetent - that would happen with or without my presence.
Your analogies are off and strange. I wont try to figure them out now, instead saving the arguing energy for the technical issues (hopefully).
[I'm curious; why do you think, in the context of an argument, that a claim that there's particular type of problem with an argument is less specific than one that doesn't even claim there's a problem with the argument?]
HandWavingis the more specific tag, and is often reasonably accompanied by a short bit of explanation as to why it is HandWaving.
I don't find it significantly more specific. And if there is a more specific explanation, then use that instead. It's politer and shorter, saving both nerves and text. The "warning others" stance is immature. It's 2nd-grade playground jocky.
Would you like some cheese with that whine? If you don't like the tag, complaining about rudeness is not the way to avoid it. Look at the man in the mirror; ask him to change his ways.
It harms this wiki in general. It makes it appear as if it's full of rude arrogant know-it-all fan-boys, which are too common on the web already. We have to learn to not only control our emotions, but also learn to not rationalize the negative emotions by wrapping them in legitimate-sounding justifications. Warn readers via the actual facts, not your personal summary conclusions. Warning doesn't scale. If all parties engage in it often, it creates a wasteful mess. Everybody thinks themselves are "right".
Civilized, reasonable, and professional people don't commit HandWaving so often that the warnings about it begin to seem rude. There are only a few individuals who consistently require a warning, and consistently fail to improve their behavior. Issues of 'scale' aren't nearly so problematic given those circumstances. If improving the wiki is your goal, I suggest you ban the biggest cause of rudeness and HandWaving on the wiki. Hint: that's you, TopMind.
You define rudeness as "acting like a practitioner". But this wiki is not meant for only academics. Practitioners are needed to keep academics honest, to RaceTheDamnedCar. Like most other insults, you stretch the meaning of it far beyond normal English to conveniently place my style into its camp. I could redefine certain annoying behaviors of yours to also be "rudeness", but it would only dilute the term. Further, even if true, two wrongs don't make a right. Me committing sin A does not give you license to commit sin B. I generally only perform "traditional" rudeness out of retaliation or as a personal catharsis, and do so sparingly. I'm pretty sure that if you marked up "traditional" rudeness with two colors for each side, my debate partners' rudeness would clearly exceed mine. And again, "HandWaving" is useless when it lacks specifics. - t
[Where has rudeness been defined as "acting like a practitioner"? I see no practitioner vs academic dichotomy here, except the one you manufacture by your own reluctance to educate yourself (which is entirely unlike any interested practitioner I've ever met) and then when called to task for it, claim that you're representing practitioners, etc.]
Most practitioners are intelligent, reasonable people that are willing and able to take opportunities to educate themselves before entering an argument that interests them in order to avoid embarrassment and rudely wasting the time of everyone else. You, TopMind, DO NOT represent practitioners, and it is arrogant and rude (to other practitioners) to claim you do. When was the last time you 'raced the damn car', TopMind? TableOrientedProgramming? TypesAreSideFlags? ObjectivityIsAnIllusion? CrossToolTypeAndObjectSharing? GuiMachineLanguage? It seems to me that you think much more of yourself as a practitioner than evidence supports. You indulge in MentalMasturbation but race no damned car, produce no implementations, and you don't even present reasonable arguments.
Again, you are widening the definition of "rudeness" beyond it's normal usage. I believe in SelfStandingEvidence (given a few prerequisites), and you don't. That's a philosophical difference, not rudeness. You are erroneously re-projecting a philosophical difference into "rudeness" for some reason, perhaps as a red herring to distract from your frequent name-calling sin. A philosophical difference is NOT rudeness. And whether I am guilty of not RacingTheDamnedCar? is a separate issue which I will not address here. (Hmmm, how does one race TypesAreSideFlags?) And my arguments ARE reasonable. You just ignore them because they are not your pet technologies. You are blinded by the pursuit of your overly-complicated God Language because you dig them as a hobby. At least I realize that my pet technologies may be subjective preferences, which is not necessarily a bad thing. But I don't insult someone just because they prefer something else. - t
[Sadly, your arguments are largely not reasonable. Sometimes (like TypesAreSideFlags) they are almost comical. Your reluctance to educate yourself means -- to use an analogy I've used before -- you either wind up arguing the merits of wooden pistons, or deprecating forged aluminium pistons, to racing engineers. Unfortunately, just like arguing the merits of wooden pistons to racing engineers, the engineers' attempts to explain how ridiculous wooden pistons are in terms of centripetal and centrifugal forces, metallurgy, materials, gas pressures, and so forth, make no sense to you. When the engineers appeal to your layperson's background and point out that wooden pistons will break, swell and burn in seconds doesn't help, because you know so little about engineering that you're convinced the engineers are wrong. When the engineers suggest you try building an engine with wooden pistons, you claim to be busy with other projects, not an engineer, etc. And on it goes. It also doesn't help that you start the trouble by insulting the engineers' work. Phrases like "overcomplicated <x> because you dig them as a hobby" does nothing to help your case, and you've done precisely what you deprecate -- you've insulted someone because they prefer something else.]
TypesAreSideFlags is not a good example because it's about definitions, not about tools being "objectively better". And the wood pistons could not compete in a race, they'd burn up or blow apart. Let the results do the insulting, not your mouth. Thus, the yapping before the race is a moot point. Further, until the race is done, each side should be respected, even Mr. Wood. Prove somebody wrong with results, not preliminary jabber. Everybody thinks their pet design and tools are the cat's meow. People are inherently arrogant. - t
[What a page is about is irrelevant. Your argument (the substance of which was that "types are side flags") was characteristically unreasonable, as unreasonable and as based in ignorance (in the lack-of-knowledge sense) as advocating wooden pistons. It's nice you're aware they won't work -- thus saving us an unpleasant side-argument -- but that isn't relevant here. They're an analogy, not a point for discussion in and of itself. As for suggesting that "Mr. Wood" be respected until, presumably, a race is run with wooden pistons, that is ridiculous. Wooden pistons are recognisably ridiculous to anyone with knowledge of racing technology. Anyone who argues otherwise clearly knows nothing about racing technology. Unfortunately, some of your arguments are precisely analogous (TypesAreSideFlags, for example) -- they do nothing but highlight your lack of knowledge: Simply replace "racing technology" with "ComputerScience". The problem is that you apparently know so little about ComputerScience that you're not aware of the mistakes you're making, and don't understand our explanations and (sometimes aghast) reactions, either.]
Further, the "Microsoft GUI Sabotage" episode has demonstrated that it's not just about academic knowledge or BookStops. Your treatment of my assessment of MS fit the same pattern as those debates that were tied to academic books. You have no more insider knowledge about MS than me, you have no thesis/theory on predictions of MS's behavior, yet you treated my assessment of MS's behavior as if you did, calling it "illogical". This lends evidence to my theory that you are merely hot air posing as an academic expert. You mistake personal opinion for universal truth. I caught you in a lie. - t
[You confuse me with someone else. I have never commented on "Microsoft GUI Sabotage".]
That's the one I've been using for argument analysis and dissection purposes. Do you have another example of me being bad that that doesn't involve definitions? Or simply read the MS debate and form your own conclusion and evidence. Further, if I was making blatant mistakes with ComputerScience, then they should be easy to demonstrate. Kill me with brilliant demos, not personal attacks and name-calling. If you cannot do that, then I'll conclude you are merely full of hot air. Be a brilliant genius by deeds, not by mouth.
[Another what? I don't see the relevance of anything from "Further, the 'Microsoft GUI Sabotage' episode ..." on down. Your mistakes were demonstrated often and well. As I pointed out above, you apparently know so little about ComputerScience that you're not even aware when your mistakes are being demonstrated.]
That's because you are not turning them into anything sufficiently tangible except very narrow criteria like "type safety". Optimizing a narrow set of variables is not sufficient. You've not demonstrated that you can optimize a wider set of criteria. I'd have to say that you are "anal" in your focus if I was going to be rude.
[We show you a page of arguments about why wooden pistons won't burn up, and you still want us to build you an engine with wooden pistons. Guess what? We don't have to. We know they won't work, and we don't have to build an engine to prove it to ourselves. It really doesn't matter whether you believe it or not, and we certainly don't have to prove it to you.]
Even if that was true, is that justification for you being rude? State your opinion about wooden cylinders and move on instead of repeatedly and repetitious attacking Mr. Woody. (And, your complicated God Language is perhaps the wooden engine.)
[When Mr. Woody persistently states his own goofy and ludicrous arguments in favour of wooden pistons and ignorantly criticises forged aluminium pistons, it should not be surprising to Mr. Woody that when he rejects the engineers' suggestion that he get some education just like they did, they react with a certain amount of exasperation and that their persistent exasperation leads to occasional rudeness.]
Just because Mr. Woody may not speak the same lingo does not by itself make him wrong. One should look at Mr. Woody's arguments. If they are fallacious, then use something close to formal logic to deflate the arguments. Surely smart and reasonably-articulate academics could do that. Perhaps Mr. Woody may even expose some untested assumptions made by the academics. Why leave them untested? Thus, both parties may learn something even if one party is wrong. Good communication is like this.
[All well and good if Mr. Woody said anything of merit. Unfortunately, the merits of Mr. Woody's arguments exist in his mind alone and are obviously ludicrous to the engineers.]
If you want to debate him properly, then use your expert engineering knowledge to bash his arguments left and right. Create a model of wood under estimated stresses, for example. If he disagrees with the model, then ask which givens he disagrees with (such as assumed temperature of combustion chamber), and focus on that aspect using standard western reductionism (similar to StepwiseRefinement) to isolate where the difference are. If's he's truly a crackpot, you should corner him pretty quick. If he has good counter answers for all the stuff you throw at him, then perhaps he deserves a listen. I've been in debates like that both where I win and I lose. But 80% it comes down to LaynesLaw unfortunately. For example, someone claimed I'd have to change code in every module in a book/media library example to add new "media types" using P/R. In the end it turned into LaynesLaw over "types". Somehow they weren't "types" if tracked via tables instead of formal language types in his view. I ended by saying, "call them whatever you want, I still don't have to change each module to add a new media 'kind'. I care about productivity here, not labels. - t
[Various correspondents have done precisely that against your arguments, repeatedly. Like all crackpots (your term, not mine), you refuse to believe it when you've been cornered.]
You guys don't use reductionalism, but BookStops. That's why I wish to explore a Microsoft example this time (per below). You can't BookStop your way out of that one. Bring it on!
Further, some of you who criticize me suggest that ComputerScience is not really applicable, and that I am seeking "economic" or "engineering" concerns, not pure science. But I never get the full story on this. - t
[It's quite simple. You are seeking certain answers from the wrong field. Sometimes, your arguments are effectively asking the racing engineers to justify, on a racing engineering basis, their choice of paint colour on the body shell. That's not up to the racing engineers to decide. Similarly, some aspects of IT systems projects are not ComputerScience, but belong to economics (determination of value, for example) or engineering (e.g., determination of the "best" choice of language, technology, or tool.)]
Please clarify "seek" and "from the wrong field".
[Huh? You seem to want, for example, ComputerScience or something to provide a rationale for object oriented programming, various degrees of type safety, etc. That is not the role of ComputerScience. It may be the role of economics (to determine its applicability in value terms, relative to alternatives) or engineering (to determine whether use of OO or a given level of type safety under a given set of conditions is a "best practice" or not.)]
How does this relate to say the GuiMachineLanguage argument? I never said it should only be evaluated from the perspective of ComputerScience. Or even definition debates such as TypesAreSideFlags, one you listed. Maybe using TypesAreSideFlags is more economical because employees relate to it faster. - t
[I note a distinct lack of support for GuiMachineLanguage, and a number of comments against it. The same holds for TypesAreSideFlags. More wooden pistons, that. Whilst I do recognise the fallaciousness of AdPopulum (or its complement), the total lack of support should cause you to question your notions and note that you're the only one in favour of them. Isn't that exactly what you'd expect for a Mr. Woody who endorses unsustainable ideas?]
Two people? Wow. I'm so overwhelmed. I gave a long discussion on why MDI is needed, and I don't see any deep counter thinking. They simply went away. They could have given web-oriented alternatives to dissect and compare. You could have overwhelmed me with specific GUI scenarios and answered each and every GUI scenario I proposed with a decent HTML++ version. But you didn't; merely claiming victory by claiming victory. You are talking heads, not do-ers, not show-ers. And that GUI topic is not about academic knowledge, so my call-wolf point still stands. I am hounded by a small group of habitual biased exaggerators who are retaliating for having their SacredCow attacked. - t
[No, it's simply that your rambling, uneducated monologues eventually aren't worth the effort of one more response. I wish you'd attack a SacredCow, because that would be interesting. Unfortunately, you're nowt but Mr. Woody, with whom the engineers eventually grow weary of arguing about wooden pistons and go back to doing real work when it becomes apparent that the only thing that might convince Mr. Woody of reason is to create an (expensive, pointless and time-wasting) engine with wooden pistons. Of course, everyone else knows wooden pistons are ridiculous, so why bother? Mr. Woody isn't worth the effort.]
Whose this "everyone else"? Don't flatter yourselves. And you are NOT any more of a GUI design expert than I am. So knock it off with the education pretense. You've been exposed because your accusations in the GUI arguments are no different than they are in "ComputerScience" topics. You appear to be frauds based on the GUI thing. It got so habitual for you to play the academic YouJustDontGetIt card that you collectively accidentally used it in the GUI design realm, which you have no claim to special knowledge, and thus caught with your excuses down. Just fess up to your erroneous debate ways and correct them instead of trying to project them back on to me. You guys fucked up and got caught. - t
[Huh? That doesn't even make sense.]
Where's the problem?
[I don't know what "GUI design expert" has to do with any of this. I don't know what has apparently been exposed. I don't know what fraud we appear to have committed. I don't know what you claim "[us] guys" have apparently "fucked up" on and have therefore "got caught". Your declaration of victory, if that's what it is, is quite bizarre. It's like you've been caught with your pants down, and are pointing at folks with their pants up and going "hah, hah, your pants are down."]
Your complaints about my evidence in the GUI discussion are basically the same complaints I see when we discusses "academic" oriented topics, such as "being illogical". Your claim was that I am not educated enough to understand your counter-arguments for the academic topics. However, that doesn't work for the GUI topic because academic evidence was not used. You have to find a new complaint for my GUI evidence or admit you are playing games.
[My claim that you are not educated enough is clearly demonstrated on TypesAreSideFlags and GuiMachineLanguage. This has nothing to do with whether "academic" evidence is used or not. Your narrow, uneducated viewpoint is in evidence throughout. It would appear to apply to the broader InformationTechnology and SoftwareEngineering worlds, which encompass GUI issues, in addition to ComputerScience. Furthermore, it would appear the majority of sub-arguments with your correspondent are precisely over ComputerScience issues (such as language design & security) and your lack of understanding of them.]
Where has lack of "sufficient education" been demonstrated in GuiMachineLanguage? I've asked for examples multiple times. Please, don't be vague.
[Everything from 'Security Issues' on down is indicative of your lack of understanding, which your correspondent has patiently attempted to address and you've made a concerted effort to resist. It isn't the case that you and your correspondent are equals who disagree over priorities, or the significance of evidence, or interpretation of terminology or results. It is the case that you appear not to understand fundamental ComputerScience and computing issues, and your correspondent has made an effort to explain them, and then you've disagreed with what is otherwise held to be canonical knowledge within the field. Of course, there's nothing wrong with disagreeing with canonical knowledge, but if you're going to do so, you need to make an exceptional effort to demonstrate that you are right and the canon is wrong. As a specific example, note the exchange under "is a pet language mostly for TopMind's MentalMasturbation", in which you appear to demonstrate a surprising lack of awareness of the IETF and W3C and their influence on Web infrastructure.]
Your "security system" is completely different from what is currently out there. Your argument is, "If you don't use my grandy dandy security system, then your product will stink." The argument that a standard that is very different from what is out there are less likely to be adopted is perfectly valid and one that most readers would likely agree with. You are just trying to sell your HobbyHorse via intimidation and insults. How about we LetTheReaderDecide if anything that doesn't use your favorite technologies is "illogical". All debates lead to roads that lead to your damned HobbyHorses. Most just want a decent GUI system, not a big new convoluted God Language that tries to out-do Emacs in feature count. I've had enough of your obsessive and rude nature. If you want to evangelize things like CapabilitySecurityModel, then show realistic scenarios of it saving cats from trees or whatever the hell it does, rather than call everything that doesn't use it "illogical". You are a stubborn rude fool. Go back to your mother's basement and stop harassing C2. By the way, HTML++ doesn't use your pet technologies either. Does that make it's selection "illogical"? You are so @#*$% annoying, damn! - t
[Nice rant! However, you are confusing me with someone else. I have not written anything on security on this Wiki at all. I referenced 'Security Issues' only as a starting point for indications of your lack of knowledge. It goes all the way down, so please don't focus just on 'Security Issues'. Furthermore, you are focusing on the wrong issue about the, uh, issue. What is significant is not whether CapabilitySecurityModel is superior/inferior/tastier to/than AccessControlLists and the like, but the simple fact that you attack it without knowing anything about it. I doubt you've even bothered to put 'Capability Security Model' into Google and spend ten minutes reading about it, which would phenomenally increase your knowledge of the subject. Of course, you still wouldn't know a lot, but at least you'd know more than zero, as any measurable quantity is infinitely more than zero. The problem here is that you have closed your mind to alternatives without even considering them. That is the basis of your lack of foundation knowledge of computing, ComputerScience, SoftwareEngineering, and information technology. You've decided you know everything that needs to be known in these fields, except the most fundamental fact of all: That you might not know enough.]
The topic was not about security models. The primary debate was comparing GML to HTML++, and you never showed a specific scenario that exposed a significant flaw in GML that HTML++ didn't also have. Instead, you or your like-minded buddy try to force it into a debate about GML versus your favorite security gizmo because you like talking about your favorite security gizmo. It appears to be nothing more than an irrational obsession and/or evangelism disguised as debate. And I have looked up CapabilitySecurityModel on the web. It appears only a handful of mumbly academics give a rat's ass about it. Based on the style, I even suspect that you or your like-minded buddy wrote most of it anyhow. - t
[Nice AdHominem attacks! You are aware that RudenessFails, yes? I never showed a "specific scenario that exposed a significant flaw in GML that HTML++ didn't also have" because I never edited the GuiMachineLanguage page except to add a few inconsequential points, and to ask a question about whether GML has any reason for being or not. I'm still waiting for an answer that justifies GML's existence, but don't feel rushed to provide it. Your GML is only remotely meaningful to me when it actually exists, and when I can choose between it and its alternatives. Until that point, it is vapourware that presents no new ideas and is therefore essentially ignorable. If you were seriously going to build it, it might be worthy of consideration. As there's no evidence you will build it (I doubt you can), there is every evidence that it will remain vapourware in perpetuity, and therefore it is not worthy of consideration. At best, the GuiMachineLanguage page should probably be deleted, as it represents a fantasy every bit as disconnected from reality as any post by SchizoidGibberishWikiAuthor.]
{I asked for reasons to use GML - reasons someone like me might wish to support its implementation - and you fed me (among other things) some lines about 'security'. You, TopMind, appealed to security, and yet you demonstrate an appalling ignorance of computer security concerns, and you make no effort to repair that ignorance. Also, if I want the flaws of HTML++, I might as well stick with using HTML++. If you are trying to improve on HTML++, then ought to defend differences from HTML++ (e.g. in terms of columns, cookies, scripting, client-server interaction, routing of user input, ability to readily associate updates with particular relations in a database, etc.) on the basis of improvements from HTML++ and any resulting FeatureInteraction. You certainly should avoid appealing to 'security' or 'anti-fanboyism' or other 'advantages' without strong justification - behavior like that earns the tag 'HandWaving' whether you do so from ignorance or to avoid difficult questions.}
Just because something does not improve on every feature point does not mean it's not competitive.
[But... GML doesn't appear to improve on any feature point! GML's benefits are listed in 'Goals', right? (I can't find any other clear delineation of benefits.) I see nothing there that demonstrates how GML improves on HTML++.]
Well, you are being dense then. I explained it in plenty of detail. In summary, HTML++ is growing too bloated, extending existing tools and standards far beyond their intended use. You may dissagree with the general conclusion and believe they can bend sufficiently, but I gave plenty of details and examples for my point of view.
[What? I still see no clear delineation of GML benefits! Where are they? Give me a PageAnchor or something. Merely identifying the flaws of HTML++ does not constitute a description of the benefits of GML. You need to demonstrate how GML addresses each of the flaws you've found in HTML++.]
That's like saying that the NASA's Aries rockets cannot be criticized until the alternative is fully built in order to compare. That may not be economical. It would be nice if there was a working version of GML, but there's not. However, we are planning for the future, and the industry has to decide whether to continue to try to put all effort into HTML++ or also put some into other approaches in case HTML++ can't bend sufficiently. Neither side has a certified peer-reviewed formula that says their path is right. You cannot prove with hard logic that HTML++ will sufficiently bend. Thus, don't demand hard logic from me. I propose a hedge whereby two very different paths are taken (extending versus starting from scratch) rather than put all eggs in the HTML++ basket. I believe I made a reasonable argument. It gets back to my complaint about you guys loosening and tightening the evidence-hardness knob in an uneven and unfair way. HTML++'s future gets a loosey goosey setting for the pass criteria, but GML doesn't. You want a OfficialCertifiedDoubleBlindPeerReviewedPublishedStudy or formula for it. - t
[You've completely misunderstood. I've said nothing about building GML. I've said you need to indicate what the GML benefits are. Merely criticising HTML++, and then saying, "Oh, and here's GML!" does nothing to indicate how GML is intended to address the criticisms of HTML++. Give us a side-by-side comparison of HTML++ vs GML that shows how GML addresses each of HTML++'s flaws, and then you may be onto something. Until that point, you've essentially offered nothing but a name (GuiMachineLanguage) and an illustration of structure, without even a suggestion of why that structure is superior to HTML++.]
A "feature contest" is not the heart of the matter. The heart of the matter is whether HTML++ can bend enough to create stable CRUD-friendly GUI's, given vendor/version-multiplicity and cooperation issues, and non-SystemsSoftware languages taking over the role of SystemsSoftware. There's too many hurdles in the way to not start thinking of a hedge (backup alternative). Why the hell do I have to keep repeating this? If there's a lot of hurdles, then a hedge is generally a good thing, no? If no, what are the exceptions that apply here? - t
[Huh? Ok, what makes GML superior to HTML++ for creating "stable CRUD-friendly GUI's, given vendor/version-multiplicity and cooperation issues, and non-SystemsSoftware languages taking over the role of SystemsSoftware"?]
Sigh, that's what we've been discussing. I'm not going to re-paste those 20-odd pages here.
[Under 'Goals', there appears to be what could be turned into a list of features. The remainder is fruitless debate, occasionally reminiscent of something that might be describing a feature or two, but mainly devoid of content.]
Again, it's not just about "features", but also a stable architecture and infrastructure. But if you want to revisit featureness, then try WebBrowserMissingWidgetWorkArounds yet again.
[How does GML demonstrate "stable architecture and infrastructure"? As is so often is the case, you seem to have clear details in your mind of how GML is superior to HTML++, but it doesn't appear on any page. WebBrowserMissingWidgetWorkArounds provides a nice list of widgets, but the relationship between these and GML appears to be vaguely implied rather than explicitly stated.]
As already described, the main reason is that it does not have to depend on e-brochure baggage, excess vendor and version "diversity", MS-controlled libraries/engines, and scripting languages used as a systems programming language. I would point out that OracleForms? sort of pulled it off by using Java. An OSS attempt at something similar, but not bound to OracleForms?' CUI-derived idioms could use some of its lessons.
[These goals are laudable (though they're hardly "already described", it's more like "vaguely alluded to in the midst of debate"), but what's still not clear is how GML achieves them. I keep expecting to find language like "GML defines event handlers using <x>, thus avoiding scripting languages, which is desirable because of <p>" or "GML uses <y> to implement graphics, thereby avoiding MS-controlled libraries/engines, which is desirable because of <q>", but to the extent that this writing exists at all, it seems only to be in response to criticism, as if your ideas have been derived solely in defense instead of considered as part of the design. However, I can see considerable value in an OracleForms?-like toolset for building Web-based business applications. I would (actually, I have been) build(ing) it in Java, though, and not bother with GML. I can (almost) consistently convince my users to install Java and its browser plugin; it's almost impossible getting them to install any other plugin without a very, very sound rationale. Thus far, the rationale for GML has been so weak and diffuse (and it's vapourware!) that I'm not sure why I'm even bothering to finish thi]
Regarding scripting languages, see GuiMachineLanguageDiscussion, pageAnchor scripting_ties. Features like this will not completely eliminate the need for client-side scripting, but will greatly reduce it because common CRUD idioms are built-in.
[pageAnchor scripting_ties is typical of your exposition -- it's a single example, which is apparently illustrative to you but conveys little to me. I see no description of intent, philosophy, grammar, intended features, and so on.]
How many examples until you are happy? I cannot read your mind. I've stated plenty about the "philosophy" of design and intended features. Perhaps you just forgot or didn't bother reading them. By "grammar", do you mean GML (M=machine) or the markup representation?
Regarding "GML uses <y> to implement graphics" - If you wanted to know specific kits that could be used, why didn't you ask before? Possibilities include Java's GUI engine (perhaps with Java stripped away), GTK+, Qt, and wxWidgets.
[That was intended as an example, not a specific question. I am not so much interested in the specific kits as an overall description of intended GML features and benefits, such that it can be compared to HTML++, etc. Getting a clear, technical exposition from you is like pulling teeth.]
Getting a clear description of what the complaint is from you is like pulling teeth. Ask me for examples of things that concern you most, such as "how might you do X, and what would the markup version and server i/o steps look like?".
Re: "build(ing) it in Java, though, and not bother with GML." - One of the goals is app language neutrality, in part so that one doesn't have to master and use one GUI kit for Php, another for Java, another for Perl, another for Python, another for PL/SQL, etc. A mostly declarative approach is usually the best way to go about this because declarativeness is easier to share with different languages than behavior. (I'm pretty sure I said this already somewhere.)
[I'm not clear why you consider "declarativeness ... easier to share" than imperativeness, nor why you think a new language <x> is more "app language neutral" (whatever that is) than some existing language <y>.]
An example is the RegExp example referenced above. If done procedurally, then it would resemble IF ! regex(expr, text) THEN PRINT "Error, bad email address". Common CRUD idioms would not need explicit conditionals, loops, set/gets and no client-side scripting for that. It's similar to how with HTML SELECT statements you don't need code like "myPulldownList.addItem(myItem);" Thus, there's no worry about which app language the "addItem" will have to be coded in. (It may still allow explicit scripting for such as a bonus.)
I know you think my evidence is "weak and diffuse", but I don't know why. You are not communicating to me what is missing so that I can fill it in.
[I've repeatedly said that there is no clear delineation of why GML is worth considering over HTML++, only vagaries. I'm not sure how to make this more clear.]
It's not clear to me what's not clear to you nor why it's not clear.
[Whatever. It just dawned on me that despite of having a kick-ass job, a successful OpenSource project, a mind-bendingly quick motorcycle and the best motorcycling roads in the world at the end of my driveway, a freakishly-fast German sports-saloon car, a detached house in the country with a two-car garage, and a staggeringly beautiful and intelligent ex-actress/model girlfriend who switched careers to go into information technology (specialising in databases), here I am arguing with Top. WHAT THE HELL IS UP WITH THAT? I have everything a geek could want, and yet I waste my time here. If I could gain even an ounce of sense, I'd stop ri]
Because geeks like puzzles more than a brochure lifestyle. It just sometimes takes a while to realize that due to jewish/mormon/republican ideals pounded into you via your upbringing.
[Actually, my upbringing was the diametrical opposite to those ideals. It's not that you present puzzles, it's more that you're like a broken tooth: painful, horrible and yet almost impossible to keep from poking repeatedly with one's tongue.]
{Agreed. On the other hand, you need to improve on many features in order to gain traction against the VirtuousCircle that is a monopoly in SystemsSoftware.}
I did point out some security improvements, but you disagreed with them (surprise surprise) without being specific. But even if we ignore that, not improving on HTML++'s security model is not a show-stopper.
{You did not point out ANY security improvements, TopMind. You are simply ignorant enough to believe you were talking about security improvements. You might as well have said, "and, for security, the background color of every CrudScreen will default to blue", for all the sense your 'security improvements' make to someone who studies the subject. If I promoted a variation of HTML++ with a default 'blue' background color on the basis that the blue color improves security, would you agree? If not, what specific thing would you disagree with, TopMind?}
Just because YOU are obsessed with feature X does not mean the whole world is.
{Agreed. The world at large isn't obsessed with CrudScreens or performance, either. While the world does not 'obsess' about security, it certainly maintains a healthy interest in the subject (thus HTTPS, the prevalence of passwords, the concerns for identity theft, use of virtual private networking and secure shells, etc.). People want to share and collaborate and delegate, and they also want privacy and security. Computer security is all about achieving these features at the same time with minimal costs to performance and other features. As a point, though, I'm not obsessed with security; I am only well versed in that subject (among many others) as it is of interest to my projects.}
I didn't balance feature-sets based on your preferences, but instead what I felt are typical developer preferences. (And tight database association is called "bound controls" in Microsoft-speak. I've yet to see it perfected. It looks nice on paper, but suffers from EightyTwentyRule and other problems in practice.)
{I don't expect you to balance feature-sets based on my preferences. However, I do expect that your arguments properly justify that the design achieves features balanced to your preferences (or what you consider to be typical developer preferences), and that your design is competitive with existing products.}
I believe I have. If there's a gap in the explanation and you point out specifically and clearly what and where it is, I'll repair it.
{The whole explanation sometimes is the 'gap'. I presented you a challenge above: if I promoted a variation of HTML++ with a default blue background, explaining that this improves security, specifically and clearly what and where would you point at as a gap or error? Can you formally prove a fallacy in my reasoning? (Oh, and don't you dare suggest a BookStop - I know all I need to know about security... I want SelfStandingEvidence, and you had better make it clear even to a practitioner like me.)}
No, we are going to dissect the Microsoft issue, NOT security, for reasons already given. Sorry, but I'm taking you out of your comfort zone this time, bub. - t
{You have not made a convincing case that there is a "Microsoft issue", TopMind. Sure, you can make a decent argument that Microsoft will attempt sabotage, but you have not made a case that Microsoft can succeed at sabotage in such a way that (to be relevant to the argument) leaves GML - as it will stand at the time of sabotage - at a significant advantage, nor have you convincingly argued that GML is significantly less vulnerable than HTML++ to the sabotage (indeed, the majority of 'sabotage' plans you list in LimitsOfHtmlStack aren't even specific to HTML++). There is a step missing in your argument as a whole: you provide no strong causal relationship between the probability of Microsoft attempting sabotage on HTML++ and the relative value of GuiMachineLanguage. In that sense, the whole sub-argument is no better than my above explanation that the blue default background color is for security, in which I provide no strong causal relationship between default background colors and security... which, not coincidentally, is why I raised the above analogy.}
I've given plenty of evidence that MS may succeed in sabotaging HTML++. I cannot read your mind so I cannot evaluate the thought process (or lack of) in your head that makes you say otherwise. You are like a vending machine without prices: I keep feeding it loads of quarters and it gives me no feedback other than "insufficient money given". I can't tell whether it's broken or irrationally greedy. MS has clearly been selfish and sneaky in the past and you've offered no reason to suggest that they'll just stop.
{Arguments, points, and evidence are not like coins in a vending machine. Add two quarters to a vending machine, and you're another step closer to buying an unwholesome meal. Add the same points twice to an argument, and you're no closer for doing it the second time. Example: repeatedly saying that Microsoft has a history of sneakiness is not cashing in each time as an additional contribution to your argument, since I have already accepted that Microsoft will 'attempt' to undermine competitors, including HTML++.}
But each sub-argument is a new sub-vending machine, and you recursively end up doing the same thing. - t
{I'm not going to belabor this silly analogy.}
I'm just trying to communicate what the frustration looks like from my perspective. If I failed to communicate sufficiently, then I apologize. I don't always succeed in communication attempts, but it's NOT PURPOSEFUL MALICE.
Further, keep in mind that the probability of any one hurdle does not have to be high for HTML++ to fail. Even if there's a 75% chance that MS won't be able/willing to sabotage HTML++ and a 75% chance that vender and version differences won't significantly hinder the utility and maturity of HTML++ and a 75% chance JavaScript can handle the task of acting like a SystemsSoftware language, if you multiply those all together you get about a 40% chance of one or more of them happening, sticking us with a shoddy tool. 40% is plenty enough to trigger looking into a hedge. (I didn't list all, only the biggies and don't agree with 75%, except for the sake of argument.)
{You should learn that points are only relevant in context. Most of the above points are not related to the alleged "Microsoft issue", so while they may be relevant in another LimitsOfHtmlStack argument, they aren't relevant in this one. Hearing points irrelevant to a given sub-argument is simply irritating. Saying points irrelevant to a given sub-argument is at least disorganized, at worst irrational.}
See below for why I brought up the probability issue.
Please clarify "relative value". GML has less risk exposure to the hurdles described. The strategy chosen was done largely to get around them. - t
{"HTML++ and the relative value of GuiMachineLanguage" is, of course, the value of GML "relative" to the value of HTML++. And the only described hurdle that is relevant in context of your assertion that there is a "Microsoft issue" is "Microsoft attempting sabotage". Pointing at other hurdles is not relevant, not a cogent defense that there is a "Microsoft issue", and therefore must be rejected. If you want to buy one "Microsoft Issue" from my vending machine, you need to use the correct coins. It is my impression that you lose track of the sub-argument very easily, TopMind. Did you not, above, demand we focus on the Microsoft issue?}
I'm pointing out that I agree that MS may fail at an attempt to sabotage any given standard or competitor, but that certainty is not necessary to reach the level to trigger a hedge. Your wording implies that I need to show with near certainty that MS would succeed in sabotage. I wanted to make sure that near certainty is not a requirement. The context does matter when it comes to the full model of failure. It is a contributor to the failure chain and it's position in that failure chain affects the impact amount it needs to assert to affect the outcome.
{If you want people to help you on the effort necessary to build GML clients and servers, I suspect 'triggering a hedge' isn't going to much help your cause, especially given the number of hedges that already exist, proprietary and otherwise (Swing, WPF, Wx, TK, GTK, X11, Qt, SDL, Flash, Silverlight, XUL, XAML, GWT, etc.). While it is merely a recommendation, I suggest you argue your case honestly.}
Hey golly gee, all this time I've been arguing dishonestly. Thanks for pointing that out so that I can stop being bad and evil. Thanks for the wonderful tip, dear Comrade Twit.
{Defend GML as a WebApplication platform against all opposition it is likely to be compared against by potential users. Keep in mind that GML is starting out way behind everything that already has an implementation, and that changing this status is not cheap. And do not dodge attacks by diving for cover into the argument of becoming yet another 'hedge' for HTML++, since that's a betrayal of your vision.}
Again again, current OSS attempts keep making the same mistake: "extend/bend things originally meant for e-brocures to be desktop-like and/or CRUD-friendly", and the result keeps failing. I am not claiming I have a sure-shot fix. I'm just pointing out the reasons for the repeated failure and suggesting that a complete change in strategy is worth a college try. We cannot build the future by finding the magic formula. It takes trial, error, failure, and also failure analysis. My failure analysis strongly suggests to me that the fix is to abandon e-brochure baggage and start from scratch focusing on desktop/crud and only desktop/crud. - t
{If you feel it worth the effort, give it a try. But with the quality of arguments you've been presenting, I suspect you'll be doing it entirely by yourself. Perhaps you'll finish after your first implementation of TableOrientedProgramming?}
Short of a returning time-machine, all possible evidence will likely be called "poor quality" by you.
Note that TableOrientedProgramming is a technique, not a language. A language may facilitate its use, however.
{I suspect even your time-machine implementation of GML would strike me as unimpressive. If you do get a time machine, feel free to come back and let me know how it worked out.}
Okay, but only after I use it to kill your great grandparents....twice.
{Wow. RudenessFails, but violence is okay, eh? You must be a Republican. ;}
Don't worry, you'll still exist in another time-line, just not mine.
Anyhow, this topic has degenerated into a LaynesLaw battle over what "rudeness" is. - t
[EditHint: consider moving GUI issues to a different topic if communications-related issues can be extracted.]
Top, you said 'I'm still rude sometimes, but I accept it merely as a personal catharsis, not a solution to the problem itself.' Could it be that the mentioned catarsis helps on a meta level? So rudenes does show something (see WhatStrongEmotionsShow). -- GunnarZarncke
You mean help the rudeness giver instead of the givee? Perhaps, but at the risk of agitating the receiver, further complicating communication. Perhaps the topic should be "rudeness fails to improve listener". The listener essentially becomes a punching bag for the rudeness producer. Better to go get some Paxil. -t
Scope of Illogic
Maybe there's a misunderstanding about "illogical". Are you saying that my argument itself is "illogical" because I won't consider your favorite technologies (YFT), or are you saying that I as a person am illogical for not considering YFT? The first one makes no sense. I was comparing GML to HTML++, not to YFT. Failing to compare to a third option (YFT) is not a fallacy in the debate text itself, for I never set out to compare it to YFT (other than side comments, which was a social mistake).
Neglecting to compare to YFT may arguably be a "decision error" on my part as a human being, but that's a different animal. I made no clearly-identified logical pivotal fallacies in my comparison between GML to HTML++. Whether I personally am illogical for not considering YFT, I won't even consider that at this point, other than ask why your prerequisite-heavy GoldenHammer should get a hearing before some other prerequisite-heavy GoldenHammer. But I do request that you be clear about whether my statements are "illogical" or me as a person. Or is the vagueness part of an intimidation tactic? - t
I say your argument is "illogical" because you fail to reasonably justify that your designs achieve your goals. Your attempt to develop from a vacuum, neglecting alternative technologies and the concerns addressed by them, is perhaps "unwise", but not by itself "illogical".
If you are specific about where evidence lacks, I'll be happy to flesh it out. The problem is that you are either rarely specific enough or find some way to tie it to some favored complex tool that has little to do with GUI's. I'm trying to remove issues that tie into your favored tool kit to see if I can tease out specific examples of allegedly poor reasoning to understand what makes you so eager to claim it all heavily flawed. I'm not seeing something that you are (or think you are).
Thus, what is a specific example of flawed reasoning assuming we are only comparing GML to HMTL++? If none of the world's IT problems can be solved "logically" without using your fav thingamabob, then let me know now so that I can end my attempt to figure you out.
My primary argument on GML has always been the same: your answer to "why?" is unsatisfactory. "Illogical" refers to specific sub-arguments, none of which are especially focused on GML (the word only appears twice in that page). HandWaving refers also to specific arguments - i.e. your attempts to argue 'security' benefits that are unrelated to security, your prophecies that Microsoft will somehow break HTML++ even worse than where GML is starting, your dubious anti-fanboyism marketing tactics, plus some meta-level argument about argument. Every time you start trying to answer "why?", sound and valid 'reasoning' gets left behind. The broad differences between GML and HTML (e.g. the four-column approach) are left unjustified.
Even your one reasonable sub-argument that GML is more CrudScreen-friendly on the basis of having a few extra widgets is unsatisfactory, since that saves me perhaps 20% of the ugliness associated with a typicalWebApplication: I'll still need scripts to validate inputs; I'll still have server-side and app-developer ugliness to bind inputs to the correct server side operations; I'll still need to support accessibility (multi-lingual, blindness, text search), still need to support hints and auto-complete, still need to support 'undo', still need confirmations and conflict resolutions, still need to support progress bars, alerts, and other forms of real-time updates; still need to support persistence or session recovery and mobility. I have no reason to believe GML is CrudScreen-friendly in any but the shallowest of senses. I am left wondering why you don't just tweak HTML to add a few widgets and call it a 'new standard' (goodness knows we have enough standards) - that, at least, would have easy implementation since you could easily use MozillaFirefox or GoogleChrome as a starting point for the client, and many existing tools could adapt readily to use the new standard.
Rudeness Fails