91–100 of 105 posts
God I hate JavaScript. It's the C++ of the new millenium. 10 gallons of shit in a 5 gallon hat. Dominant only because of switching costs. Fuck Javascript. Good parts be damned.
The main problem with appealing to "best practices" is this: One man's best practice is another man's anti-pattern. Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? ( https://gist.github.com/357981 ) In the absence of a quantitative engineering method with which to evaluate either ap…
"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert?" You're framing this as a disagreement between equals. It is not. There are degrees of expertise. (Total lines of production code * amount of usage) is a reasonable approximation, and those who rank highest on this scale are overwhelmingly in favor of requiring semicolons. If Carmack and Torvalds were in agreement o…
Error correction simply means "add a semicolon if it's necessary."
Earlier quoted context omitted.
You completely and utterly missed the point, in addition to just being needlessly rude. The point of your parent was "don't let the experts think for you", not "screw the experts" - that's a very important distinction. You should form your own opinions, not just uncritically adopt the opinion of some expert. It's unquestionable that expert knowledge and experience is important - but nothing beats forming your own (ho…
Who said "let the experts think for you"? No one. You were arguing against "give the experts' opinions more weight than others, often a lot more" "You should form your own opinions, not just uncritically adopt the opinion of some expert." False dichotomy again, there is a lot of ground between "uncritically adopt the opinion of some expert" and "forming your own opinion and hoping it's informed". You should find that…
When discussing coding style, you can quote experts. Or you can understand their arguments, understand the impact and tradeoffs of coding decisions, and realize why they are true. And in the case of Topcoder, about as far as possible from building large systems, you can realize that the optimum style changes and understand why.
I think there's a broad trend to treat code as magic, something where anything can happen. Most people learn coding styles by being given suggestions, and then noticing from experience that they like it better. If you reject this mindset and believe that code is orderly, then this advice changes from Wisdom of the Elders (TM) into an engineering calculation. I specialize in automated restructuring of software architecture, so this mindset is something I try hard to fight against.
Earlier quoted context omitted.
Who said "let the experts think for you"? No one. You were arguing against "give the experts' opinions more weight than others, often a lot more" "You should form your own opinions, not just uncritically adopt the opinion of some expert." False dichotomy again, there is a lot of ground between "uncritically adopt the opinion of some expert" and "forming your own opinion and hoping it's informed". You should find that…
Intellectualism is not about showing off how much you agree with authorities. Intellectualism is about thinking and understanding, eventually until you become one. When discussing coding style, you can quote experts. Or you can understand their arguments, understand the impact and tradeoffs of coding decisions, and realize why they are true. And in the case of Topcoder, about as far as possible from building large sy…
"Intellectualism is not about showing off how much you agree with authorities"
My point was that intellectualism is not about agreeing with authorities but giving proper weight to the opinions of intellectuals in the field when weighed against lay opinions or smaller groups of intellectuals.
You certainly don't seem to be arguing for the post-modern interpretation I was arguing against where expert opinion is considered "just another opinion, equally valid" so I'm confused why you think my stance is almost the opposite of what I was stating.
Earlier quoted context omitted.
Intellectualism is not about showing off how much you agree with authorities. Intellectualism is about thinking and understanding, eventually until you become one. When discussing coding style, you can quote experts. Or you can understand their arguments, understand the impact and tradeoffs of coding decisions, and realize why they are true. And in the case of Topcoder, about as far as possible from building large sy…
I don't see how this applies to me taking issue with the parents "figure it out yourself instead of letting the experts think for you" statement. "Intellectualism is not about showing off how much you agree with authorities" My point was that intellectualism is not about agreeing with authorities but giving proper weight to the opinions of intellectuals in the field when weighed against lay opinions or smaller groups…
My first comment hit the advice to always follow Carmack over the random Topcoder user. It's important to understand what makes a best practice a best practice rather than just listening. A Topcoder round and Quake differ greatly enough that the random Topcoder user is sometimes the greater authority.
You seemed to map the call to critically evaluate expert opinion to a call to ignore it, something I'm sure you've seen too much of. But it's important to understand the difference between critical evaluation and anti-intellectualism. Indeed, the former is the higher form of respect.
Earlier quoted context omitted.
I don't see how this applies to me taking issue with the parents "figure it out yourself instead of letting the experts think for you" statement. "Intellectualism is not about showing off how much you agree with authorities" My point was that intellectualism is not about agreeing with authorities but giving proper weight to the opinions of intellectuals in the field when weighed against lay opinions or smaller groups…
The opinion of an intellectual is indeed stronger Bayesian evidence than that of a layperson. But if they have an opinion, they should provide an argument to back it up, and that argument is far more important. My first comment hit the advice to always follow Carmack over the random Topcoder user. It's important to understand what makes a best practice a best practice rather than just listening. A Topcoder round and…
I'm not sure how well it applies to a subject like best practices where it's either subjective or at least fuzzy. The arguments are "in my experience this causes problems when working with other people and is more prone to errors long term". There have been no counter examples or analysis I've seen around this issue, just a "that's just what the traditionalists say" type argument. Something along the lines of your topcoder example that applied to the semicolon argument (god i hate this issue) would be very welcome.
Any critical analysis here is hard to do objectively, and there is a consensus of experts (including Eich) on one side. If i'd seen any actual critical analysis rather than a jump to "don't let the experts tell you what to do! be a rockstar!" then I wouldn't been so fast to use the anti-intellectualism card. But it's so prevalent in the node community (more than Ruby's but less than PHP's) that it's depressing.
The main problem with appealing to "best practices" is this: One man's best practice is another man's anti-pattern. Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? ( https://gist.github.com/357981 ) In the absence of a quantitative engineering method with which to evaluate either ap…
"Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert?" You're framing this as a disagreement between equals. It is not. There are degrees of expertise. (Total lines of production code * amount of usage) is a reasonable approximation, and those who rank highest on this scale are overwhelmingly in favor of requiring semicolons. If Carmack and Torvalds were in agreement o…
And google is well known for terrible quality javascript. http://www.sitepoint.com/google-closure-how-not-to-write-jav...
And finally, Crockfords reasoning about things like this seems based on the presumption that js developers are drooling idiots. For example, he recommends against using the new keyword for object creation in javascript, even though object factories can often be a huge waste of memory, because dumb javascript developers may forget to use the new keyword at times when they want to instantiate objects.
I am not saying you shouldn't listen to smart people, but I am saying that you should actually learn the reasons they say the things they do, and use your own brain when making choices.
The main problem with appealing to "best practices" is this: One man's best practice is another man's anti-pattern. Between semicolon-free folks and JavaScript traditionalists, who gets to play the role of the expert? If Node.js is popular, does that mean that Isaac's comma-first style is "correct"? ( https://gist.github.com/357981 ) In the absence of a quantitative engineering method with which to evaluate either ap…
I think using comma-first syntax as a counter example is disingenuous. Whether you're a novice programmer or an expert programmer, using comma-first or comma-last isn't going to bite you in a way that isn't immediately solvable. Omitting semi-colons, however, can cause novice JavaScript programmers serious grief. Nevermind novice JavaScript programmers – they cause me grief, and I put semi-colons everywhere! That's b…
Earlier quoted context omitted.
Indeed the link I gave demonstrates how the right IDE also solves this problem. The fact that there are many ways of solving the problem does not mean that it isn't a real problem that formatting can help address.
It means that there are ways of solving the problem that don't involve rewriting the code in a way that initially will confuse 99.999% of other developers. And it is important in our industry to write MAINTAINABLE code.
I freely remove, add, and move things to the bottom of my js classes without ever hitting trailing semis, or hitting a missing semi. I think that is more maintainable then the alternative
Earlier quoted context omitted.
The opinion of an intellectual is indeed stronger Bayesian evidence than that of a layperson. But if they have an opinion, they should provide an argument to back it up, and that argument is far more important. My first comment hit the advice to always follow Carmack over the random Topcoder user. It's important to understand what makes a best practice a best practice rather than just listening. A Topcoder round and…
In general I agree completely, standard philosophy of science stuff. I'm not sure how well it applies to a subject like best practices where it's either subjective or at least fuzzy. The arguments are "in my experience this causes problems when working with other people and is more prone to errors long term". There have been no counter examples or analysis I've seen around this issue, just a "that's just what the tra…
With semicolons, the search for the boundary between statements reduces to the search for that single character -- that means fast code skimming.
The boundary is also robust against changes; as long as that semicolon stays in place, nothing that happens within that statement can cause that boundary to become an interior.
There is an exception: Strings. This is no trouble for machines, as strings are processed by the lexer. Humans can't instantly take a string and process it as a chunk, but a UI innovation does this work for us: syntax highlighting.
As an example, consider the code:
x = a && b
foo()
x=a &&
foo()
LR parsers take advantage of this for error recovery, allowing them to find more than one parse error at a time.
A more sophisticated view is to think about syntax abstractions. Given a program like "x=y; return x;" we can create a program written in the abstract syntax "statement; statement". (The dual operation is to concretized that back into the set of all two-statement programs. This kind of relationship is known a Galois connection.) Having semicolons makes the abstract syntax unambiguous, allowing us to efficiently reason at the statement level.