@Rachel I have no clue how to respond. JoshK has simply flat-own denied the experience of all of the "dumb" users who have problems with {}'s in code. What other response is there? Denial of facts is such a shocking thing to me. Since everyone is telling me that it's just a failure to see eye-to-eye, it must be me. My experience is invalid. How else can I respond except to acknowledge that I am clearly an inferior coder?
@JoshK In which case, you're eliminating my facts and my experience. Thanks for clarifying. I knew those hours spend debugging C were a waste of my life. I guess the only consolation is that they were billable. The programmers -- I guess -- were dumb. And. Perhaps by extension, I was dumb for not finding the matching bracket instantaneously. I bow to your superior syntax-reading skills.
@JoshK So the "appeared to suggest" was the problem. Not the facts? Please be more clear in the future. It helps to be clear. You claimed to be disputing facts. You actually were bothered by an "appeared to suggest". That's good to know. I wish you had said that at first.
@Rachel Hence my question to JoshK about what it takes to make my facts suitably factual. I thought SO questions with bad punctuation would be enough. It's not. I thought Python syntax would be enough. It's not. Then you pointed out that it was actually personal. Clearly, that's the explanation. Appreciate it.
@psr Sadly. When i do change my mind, I delete all my comments. So, there's no record of me being wrong. Perhaps I should leave them there so that everyone can count the number of times I've been corrected.
@psr As @Rachel said; it's largely personal anyway. It's not this specific question and the factual nature of two of the points in my answer that were edited. It's me.
@psr I'd like to know what part of my facts are not factual. That's the question. JoshK keeps repeating a complaint that {}'s -- not used in Python -- are somehow still necessary -- in Python. And. JoshK seems to be saying that examples of programmers messing up punctuation is not actually factual enough. I'm shocked by it.
@JoshK "Python (as a language) does not conclusively prove that curly braces are “That seems to make the utterly superfluous and completely useless”." The only thing I can guess is that you're assuming (for private reasons) that I'm making an utterly blanket statement about all possible programming languages. The question was about Python. Why assume I'm saying all punctuation is bad? Is that your objection? Not factual, but some implication?
@JoshK I'm providing facts. Programmers confuse punctuation. Python does not use curly braces. Are you disputing those two facts? If so, we're done. If not, we can then look at the answer to the question. Programmers do confuse punctuation; curly braces may be popular, but they're not mandatory.
@JoshK Python (as a language) does not use {}'s. That's a fact. Are you going to dispute that? If so, we're done. If not, that indicates that -- for at least one language -- curly braces are utterly superfluous and completely useless. It seems be factual. For Python. I'm not sure what more evidence can be provided.
@JoshK The point is this. Programmers do -- all the time -- confuse punctuation. That's the fact. Are you going to dispute that? If so, we're done. If not, then, I can use that fact to conclude that {}'s will get confused. That's what I said in my answer. That's the factual part of it. Programmers will get {}'s confused. That seems to be sufficient evidence that it's factual.
@Rachel "It's possible to provide aggressive answers". Irrelevant. JoshK was challenging the facts; not having an emotional response. At least. That's what all the comments said. If it was an emotional response, then it would be more appropriate to say that it was an emotional response rather that disputing the facts. Calling questions that point out real-world syntax problems "dumb" -- specifically -- doesn't sound like an emotional response.
"its hard to agree with someone you feel you're being attacked by. " You didn't see JoshK's requests for facts in the comments (and the dispute of the facts in the comments) which preceded the dispute of the facts here. Providing facts when requested can certainly be seen as an attack. I totally get it. Answering requests for clarification is a form of stubborn attack. Thanks for clarifying that. It's becoming clearer now.
@Rachel "what he saw as subjective parts of your answer". Agreed. Well within the role of moderator. No dispute on that. When I provided factual evidence, JohnK went on to dispute the factual support. That's a bit heavy-handed in my opinion.
@Rachel "they sometimes miss the point you're trying to make". It seemed to go much further than that. It seemed like a "I don't like your answer, and I'm changing it making a claim that it lacks a factual basis." I'm not asking for infallibility. I'm asking JohnK why a common Stack Overflow question on missing punctuation isn't factual enough.
@Rachel "bring it to his attention nicely" So. Taking it to chat is not that? There's yet another channel for communication? Okay then. I guess I'll search around for that.
@Rachel "People are entitled to different opinions". Good to know. But. That's not what JoshK said, however. JoshK disputed my facts. Rolling back the edit on a closed question is certainly possible. That doesn't explain the heavy-handed editing based on a claim (i.e., "no facts") that isn't sensible.
@Rachel "A lost cause" is a conclusion. ""It's a silly personal bias a..." comes from the question. Seems indisputable to me. "This doesn't make much sense" is my actual response; if you're going to dispute my personal state of mind with me, that's rude. "people often make mistakes with curly braces" is factual.
@Rachel Since the question was closed, that's academic. What's more important -- to me -- is JoshK's claim that my facts were merely opinions. I remain shocked that my factually-based answer would be edited and then my facts repeatedly disputed. I'm quite disappointed and want to know what -- specifically -- is required to prevent that kind of heavy-handed editing in the future.
@Rachel JoshK didn't like my answer because it was somehow fact-free. JoshK then made a couple of very heavy-handed edits that did not introduce any actual facts. I remain shocked at the edits, since they did not actually add facts to the answer.
@JoshK You're simply denying my factual experience with curly braces. Is that it? My experience is of no value. Your claim is that my experience did not exist and is not factual? Is that your claim? I'm making up the hours spent getting C programs to compile?
@JoshK I object to having the "extra curly braces aren't really all that helpful" because there are actual facts that indicate the curly braces are not necessary. Python and PHP mean that they are not necessary. I used helpful as a synonym for necessary specifically because -- in many languages -- they clearly do not "help" anyone do better indentation. If you want proof, debug someone's C code where they indented correctly and omitted the '}'. I have actually done this. It's a fact.
@JoshK So. Facts involving dumb people are not facts? Really. That makes it largely impossible to have a conversation about your heavy-handed edits demanding facts. I have to somehow pre-filter the facts to eliminate the "dumb person" factor? Is that your new standard? It must both be factual and not involve dumb people. Okay. How do I do that? Can you list specific ways to determine if the question involved a dumb person?
@JoshK So. Python omits curly braces. That seems to make the utterly superfluous and completely useless. I'm not allowed to say "aren't really all that helpful" when I have a fact -- Python doesn't use them. How is Python not using curly braces anything less than a fact? I'm puzzled why you keep insisting that Python not using curly braces is not a simple, bare fact. Why?
@JoshK Do I need to go on? 100's are trivially available. If you want them, I can write a PyCurl program to get them for you. Would that help raise the point to the necessary threshold of "Fact"?
I keep getting an error, missing { after property for the following code.
<script type="text/javascript">
$(function(){
var storage = new Array("hi","h2","hi3","h4","h5","6","7","hi8","hi9","10");
// Slider
$('#slider').slider({
...
I keep getting that my javascript is missing ) in parenthetical
[Break On This Error] if ( (this.scrollTop < this.scrollH...uches[0].pageY > scrollStartPosY+5) )
function touchScroll(id){
if(isTouchDevice()){ //if touch events exist...
var el=document.getElementById(id);
...
I have an external javascript file that I want to, upon include, write some HTML to the end of the web page.
Upon doing so though I get the error Missing } in XML expression on the line that uses dropdownhtml.
Here is my code
var dropdownhtml = '<div id="dropdown"></div>';
$(docum...
@JoshK You removed the "The extra curly braces aren't really all that helpful. But people like them. " Since you removed the, I take that to mean that curly braces are mandatory. What other meaning can I attribute to your action? You removed something that sure seemed factual to me. Now you're claiming something else? The point was that braces are -- by definition -- optional. Period. You wanted facts. Then you removed this factual statement. Why?
@Pierre303 Oh. Then the question on Programmers was fairly silly. "Is it worth making Visual Assembly?" should be answered with "Visual Studio .NET has everything you need to program in Assembly". Oh.
@Pierre303 if you can have CPU-level assembler instructions in existing Visual Studio then the answer to the question on Programmers should have been "It already exists". Right?
@GlennNelson "wouldn't be adding anything new"? The new thing would be CPU-specific assembler code, produced directly, that would be faster than .Net. That seems new-ish to me.
@GlennNelson So. Assembly into machine code really is faster than .Net? And a Visual Studio for assembly could produce this machine code directly? But doing that in Visual Studio would be bad for some reason.
@GlennNelson That part of your answer made sense. The execution speed part doesn't make sense. Still. You've mentioned the JIT overhead. But you still haven't explained the connection with the "there isn't a point running assembly using the .NET runtime because the .NET runtime has a slower execution speed than true low-level assembly, and so would assembly run on the .NET runtime". That part of the answer makes little sense. And doesn't seem related the "Just another IDE" point.
@GlennNelson "obviously"? Please avoid words like that. If it was obvious, I wouldn't be confused. Why can't this silly "Visual Studio for Assembler" actually write low-level assembler?
@GlennNelson The point is this. I don't what what "Adding another step" means in your answer. I don't know what you meant. I'm trying to understand what you meant. can you add any details or an example or anything that would help me see what this step is and what's getting slowed down?
@GlennNelson It's a simple question. I don't understand .NET very well. I'm trying to learn something here. Please help me. What does "adding another step in the process" mean? I don't understand which process you're talking about.