If you're checking a value to see if it's set by testing for null/undefined, you're doing it wrong.
This is good advice for any language, not just JS.
Besides, using null as the default for an undefined value is a mistake. Null should indicate a non-value not the absence of a value. Maybe one day the static OOP languages will die so devs have a chance to learn the difference.
All these checks seem annoying but we've all seen the bar chart of when you discover the bug vs. the cost of that bug. The compiler finding the bug is cheap. Haskell is a cheap language to program in, compared to JS!
* I forgot there is no compiler in JS but let's say the linter for argument sake.
Null isn't used in JS to mark undefined variables, that's what 'undefined' is for. Unlike static/OOP languages, null is specifically reserved for use cases where a null value is necessary. Which was the point of my comment.
If you try to access an undefined variable in 'strict mode' it throws an undefined runtime error.
JSLint does, in fact, check for undefined variables and/or globals that are accessed before they're defined in the local source (ie unspecified external globals).
So... There's that...
-----
Did you happen to notice how I didn't even remotely mention Haskell or anything related to functional programming but, please, I'd love to hear for the thousandth time how Haskell's purity is going to cure the world of all it's ills. As if the Haskell community hasn't been over-promising and failing to deliver production-ready applications for the past decade.
Unlike Haskell, JS source can be actively linted while you write it rather than requiring a separate compile/build step.
With ES6 on the client-side, modules can be hot reloaded as changes are made for instant feedback. The obvious downside being, fewer coffe breaks that can blamed on the compiler.
Have fun implementing trampolines once Haskell's 'recursion all the things' default approach to lazy-loading inevitably overflows the stack and crashes your app in production. Static type checking can't save you from logic errors. See also 'memory profiling' the phrase that shall not be uttered.
Source: http://steve-yegge.blogspot.com/2010/12/haskell-researchers-...
I am genuinely interested in your point about trampolines and can you give an example? In Haskell foldl' for example allows you to process a big finite list quite efficiently without trampolines but yes the name of the function is a bit sucky I admit.
It's funny how you can criticize trampolines but then imperative code like this:
var sum = 0;
for( var i = 0; i < elmt.length; i++ ){
sum += parseInt( elmt[i], 10 ); //don't forget to add the base
}
var avg = sum/elmt.length;
document.write( "The sum of all the elements is: " + sum + " The average is: " + avg );
Is a tramp in disguise!