61–70 of 223 posts
Do I understand this right -- global variables are shared across all requests in node.js? If so, that is an insane design.
All languages used in web server that don't spawn a new process for each request have the same feature.
Am I right in thinking that the javascript /* "use strict" */ construct would have caught this mistake (just like it would have done for me in perl code)? Seems to me that some such feature is absolutely and utterly necessary in any environment where you're doing a lot of closure creation ..
Yeah, that's all he needed. Making it a comment isn't necessary either. Maybe Node should be strict by default? I can understand it not being the case for browsers that need to support legacy code, but for Node it doesn't really need to care about that.
I think, if anything, requiring it to be in a comment would have been less odd; at least comments imply a sense of "meta"-ness.
Earlier quoted context omitted.
I wasn't initialising the x variable Do you mean s/initialising/declaring/, or am I just really confused?
Yes, sorry, I meant declaring. Wrote that post in a hurry as I headed out the door, I wasn't paying too much attention.
Earlier quoted context omitted.
Yes, sorry, I meant declaring. Wrote that post in a hurry as I headed out the door, I wasn't paying too much attention.
Hmm, so you wrote a careless typo while describing your "careless" coding? Not to be harsh, but maybe it's a hint?
In any case, I'm not sure that I need a hint to tell me that doing things quickly and carelessly is a bad idea. But we all do it sometimes, in both our programming and our writing.
> I would posit here that nothing I could do in best practice (manual front-end testing, unit testing, error handling, etc.) would have caught the offending line. jshint would have caught it. You need to run jshint on your code or you will get silly errors like this. Simple.
Even better is setting your editor to run JSHint when you save a .js file, and let you know if there are problems. Not only does it avoid stupid bugs, it saves time round-tripping to the browser for trivial issues like syntax errors.
This is why I like both Scala and Coffeescript approaches. On Coffeescript vars are created for you, and on Scala, you can't not use it (you either use var or val, making it easy to change from re-assignable variables to final ones). Note that nowadays going to Coffeescript from Javascript is quite easy: http://js2coffee.org/
I don't know Coffeescript - does it implicitly create a local var when there is already a global with the same name?
Earlier quoted context omitted.
Yes, sorry, I meant declaring. Wrote that post in a hurry as I headed out the door, I wasn't paying too much attention.
Hmm, so you wrote a careless typo while describing your "careless" coding? Not to be harsh, but maybe it's a hint?
I for one would speculate, not to sound harsh, that if you haven't made silly errors like this then you haven't been around the block enough times.
Why has it become popular for dynamic languages to conflate establishing a binding with assigning it a new value? Ruby, Python, and Javascript are all guilty of this. Scheme got it right sometime in the 1970's. (let ((x initial-value)) ; binding (set! x new-value)) ; assignment Or in infix syntax (Dylan): let x = initial-value ; x := new-value ;