> Because recursion in the languages they are using involves allocating stack frames for the recursion, which means they can't predict stack depth, which means they can't predict the amount of memory the stack will consume, which means they may run out of memory, which means their spaceship may be destroyed.
Thank you. It is trivial to turn a recursive function into a loop. Trivial especially compared to running through all the stack space (1MB on Windows) and crashing the process in some runtime environments[1]. Or your space ship. Either way: recursion belongs in academics. I don't care if you are using JS or ASM, learn how to avoid using it.
> Manage your variables with respect. Regularize variables declaration by putting them in the top of scope
That really isn't what is meant by "Do not use dynamic memory allocation after initialization." Memory is allocated on the stack the second you enter the frame, no matter where you declare the variable. That is a style recommendation.
> JS is not even capable of following #3 about memory allocation.
Not to mention that the wrong definition of a GC is used.
[1]: http://stackoverflow.com/questions/107735/stackoverflowexcep...
It's a bad idea for a class of languages. Functional languages implementing TCO are a different kettle of fish (especially if your function is tail-recursive). It's an extremely common pattern in these languages.
I'd rather people learn from the other direction, you know? I'm not sure how that would be implemented, but I see recursion abuse far too often and few seem to understand how that could be a bad thing.
All those crash prone (not!) Ericsson phone switches beg to differ.
Recursion does not belong just in Academics. But just like any other tool it requires some level of understanding and when you use it naively it will bite you. To avoid such complications NASA attempts to get rid of the problem entirely. But when properly used recursion has its place, provided both the language and the programmer are aware of its limitations and pitfalls.
Other than the mention of recursion, everything else is about predictable and visible program flow. If you were to carry this forward to JavaScript you would want to avoid `throw` for application control for example.
Creating a framework within which to challenge your assumptions can be useful.
Of course the article wasn't suggesting manual testing and avoid profiling, but it MOSTLY recommended techniques and tips that do not apply to the web. That's what jerf spent three paragraphs outlining.
Because recursion in the languages they are using involves allocating stack frames for the recursion, which means they can't predict stack depth, which means they can't predict the amount of memory the stack will consume, which means they may run out of memory, which means their spaceship may be destroyed.
Which, incidentally, here on step two indicates why the NASA standards are from such a different world from the web browser that they don't much matter. Now, I'm not saying that memory use doesn't matter, just go nuts, but JS is generally running in an environment with wildly more memory than those restrictions were meant for (yes, even on cell phones nowadays), and generally you're looking at "annoying a user and they go away" being the worst case rather than "losing a billion-dollar spacecraft".
JS is not even capable of following #3 about memory allocation.
NASA: "6. Data objects must be declared at the smallest possible level of scope."
Commentary: "This rule have simple intention behind – to keep data in private scope and avoid unauthorized access. Sounds generic, smart and easy to follow."
No, that's not what that rule is for. By keeping the data objects at the smallest possible scope level, it makes it as likely as possible that it can be stack-allocated, which means the lifetime of the object can be easily understood, guaranteed not to proliferate due to a leak (see rule about not recursing), etc. Again, this has little to do with a language that decides for you whether it will stack or heap allocate.
#8, again, has nothing to do with Javascript.
"When started to write this article I could not imagine how much web world could get from NASA and how much is similar."
No, it really isn't. Unfortunately, and I don't know how to effectively soften this, you don't understand enough about their world to understand what the rules are for, so you brought your own conceptions about JS to what the rules were saying. In fact they're really specific to a certain type of resource-restricted real-time programming that has very little to do with a web browser, and which you could not follow with JS even if you somehow wanted to, and for those you could, the cost/benefit tradeoff for following NASA's suggestions are awful. If you're interested in improving your JS quality, focus on more extensive automated testing, focus on more profiling, and focus on general software engineering principles like single-responsibility and DRY. Don't even worry about these rules.