My point is more that the compiler* can't detect these mistakes but in other languages you can. E.g. in Haskell you only allow Null on types when you want it (you do this by using the Maybe type). Objects where you probe for values that could be undefined or could be defined but null doesn't exist as a concept but if you badly wanted it you could use a dictionary. In Haskell if you use Maybe and you process a Maybe object you have to deal with the null and not null case otherwise you get a compiler error.
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.
Maybe/Nothing is a perfect example of the null object pattern. Either provide a sane default or a typed instance with empty values rather than checking for null/undefined. Ie the 'null object' in 'null object pattern' doesn't mean using null to indicate the absence of a value.
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.
Purity won't cure the world of all it's ills but it may fix a bug or two before it hits ... well the developers consciousness let alone production.
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 );
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.