"It’s beautiful simple..."
I might just be painfully slow, but the implementation he described didn't sound anything remotely simple to me (though I believe it really is beautiful).
How One Missing `var` Ruined our Launch
141–150 of 223 posts
Re: How One Missing `var` Ruined our Launch
#142And that is what happens when you throw static type checking and the other safety features of compiled languages out the window, 'cause all the cool kids are doing it.
Re: How One Missing `var` Ruined our Launch
#143Earlier quoted context omitted.
Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.
JS in browsers is not multi-threaded. There's only one JS thread where requests from async calls are queued: http://ejohn.org/blog/how-javascript-timers-work/ When dealing with true multi-threading you have all sorts of issues you need to worry about, like locking for writing, worrying about deadlocks, etc. that make coding much more difficult.
Yes, I know JS in browsers is not multi-threaded. It runs multiple globals all on the same thread, as I said. Node is not multithreaded either; it could run a bunch of separate globals on the same thread as well, if it wanted to.
Re: How One Missing `var` Ruined our Launch
#144Earlier quoted context omitted.
Why does threading matter? You can have multiple JS global objects all running on the same thread. See any web browser.
Indeed you can - but I suspect I know why Node has avoided this. If you did take advantage of the runtime's support for multiple global objects, what would those global objects correspond to? The most natural scope would be "user session" - but if you go that route, now you support stateful user sessions. And before you know it you have developers storing loads of user session state in the server's RAM and wondering…
"user session" is tough, indeed.
But doing global per request would not be that complicated, if desired.
Re: How One Missing `var` Ruined our Launch
#145Am 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.
Node itself (the core js library) isn't strict mode compliant: it uses octal literals for filesystem interactions.
Re: How One Missing `var` Ruined our Launch
#146Earlier quoted context omitted.
In JS, "global variable" means "property of the global object". No reference to "process". It's trivial to have a single-process JS application with multiple JS global objects in it. Case in point: any web browser (and renderer processes don't change this: every iframe on a page has a separate global object). It's just that Node _chose_ to reuse the same global object for multiple requests instead of using a clean ex…
I have to amend my previous statement, these guys are right. I created this Python script here https://gist.github.com/1329943 and ran it. If global context were not shared, then each request would receive a new random number, but they don't. Each request gets the same number. Even without doing this experiment, the result is obvious. There would have to be some meta process to start new interpreter processes here in…
You're running your whole server in python. So yes, there is only one process and its globals are very much global. Note that you are NOT writing some program that embeds the python interpreter and then runs it on python code of your choice.
In the case of Node, it's embedding V8. It can in fact run JS code of its choice in an environment of its choice, set up new globals, etc.
Re: How One Missing `var` Ruined our Launch
#147Earlier quoted context omitted.
In JS, "global variable" means "property of the global object". No reference to "process". It's trivial to have a single-process JS application with multiple JS global objects in it. Case in point: any web browser (and renderer processes don't change this: every iframe on a page has a separate global object). It's just that Node _chose_ to reuse the same global object for multiple requests instead of using a clean ex…
(I assume) the reason that node chose to go with a single global object (which is optional[0]) is that JS gets a bit hinky when dealing with multiple contexts: e.g., an array returned from a function defined in a different context will not satisfy `[] instanceof Array`, since the receiving module's instance of `Array` is not strictly equal to to called module's copy of `Array`. In practice, this problem is why you se…
Thanks for the pointer to NODE_MODULE_CONTEXTS!
Re: How One Missing `var` Ruined our Launch
#148This is a major downside of interpreted languages, coupled with JS's diabolical scoping rules. Interpreted languages by their very nature, only reveal syntactic errors to you once you run them. I would like to see server side code written in compiled, statically typed languages, such as C/C++ to prevent such errors.
Re: How One Missing `var` Ruined our Launch
#149This was a problem of laziness more than anything else. To the beginner developers out there: Learn to write good code and to pay attention to the details. Don't become just another co-founder trying to do the bare minimum just to make a buck. Take pride in your work and use best practices. Be careful to avoid the careless mistakes made by the author... 1. Did a major last minute code change 2. Did not run jslint 3.…
Sure, blame the victim, not the idea that default variable scope is global.
Re: How One Missing `var` Ruined our Launch
#150Bad Title. There is no such thing as a ruined launch. Launches don't matter. Adapt from failures constantly, and you will be just fine.