Possible bug with unknown args to function?

@maze1980

...all other JavaScript implementations have a different understanding.

and

Being the only to follow the spec is a bug - from the user point of view. Because it's incompatible with the rest of the world.

...quite some statements.

For the first - may be reality reads ...have each their own different understanding because for the second: all - and that's a lot of, not just Browser JS, node JS, Espruino, and not mentioning the (incomplete) rest of the world - all of them live and have to keep living proudly their 'up-bringing'... like HMTL which came to be without specs - just by doing - and and trying to get it really (cleanly) spec'd afterwards with XHMTL 1.0 / HTML 4.01 failed miserably... in regard to it's (mattering) intention... blog.codinghorror.com: html validation - does it matter?.

This is quite an old (2009/03 - past 10 year anniversary) article... and the discussion ran quite hot then... and: today?

Today, some aspects of the context of html and related set of technologies - that's why it is now called HTML 5 - are obviously still running hot.

But let's not forget the context: for a lot/ some of the CS community the bad in JS (still) outweighs the good, despite the grown popularity / spread and knowledge - avaScript: The Good Parts- by Douglas Crockford: Most programming languages contain good and bad parts, but JavaScript has more than its share of the bad, having been developed and released in a hurry before it could be refined...... but the difference to many other hurried things it was refine-able (not like Java, which had to change some of its core to become useable... and it was not rushed from a time-wise, but architecturally... it had forgotten - or missed out - on aspects learned from the late 50' thru the early 80'... even though it claims to have chosen the best of the best - at that time ...a ramble about my love-h... or h...-love for Java, and that's a lot of daily bread).

I did not like the browser war nor do I like this js war. The real issues are:

Is the (application / business) problem understood? - If yes, let's create a solution for it with the tools and skills we have in the time frame where the solution still has a viable business proposition.

If we have doubt in the suitability of the tools or any of the available tools and the skills we have, let'
s make an impact analysis and refine areas... and we may end up with a hybrid approach - a good solid approach that solves the issue in the context where life happens.

Luckily, runtime environments - stacks - have refined themselves too over time - thanks to effort getting (IEEE / IETF shared) specs done and adhered to and last but not least thanks to competition on the market... Talking though to people from different camps, preferences are still alive... and may never go away, even after all things follow the specs... or more so all have adopted - accepted / implemented - each other's (real?) flaws (and goodies) - and completely different, new but shared solutions, so that code can be moved around... that's what I get the impression from today's HTML5 world and their most prevailing application environment(s).

With IoT and Espruino is it a bit different... solutions barely have the intention to be portable between stacks, because they run not on generic or universal platforms. The solutions are very targeted and specific... and therefore cater to a lot of specifics.

In the task at hand - arguments.length - I think the length should be fixed in Espruino if all possible... even though I never felt into this trap.

When it comes to the other aspect - ReferenceError - it can be refined too: initially JS did not complain about undefined references, it just assumed that it is intentional. Therefore it has been introduced in Espruino so that such issues of undefined can be detected much more easily... also by maker's of whom the majority do not have a CS degree and life long professional CS deformation... How ReferenceError has been implemented may even be hampered by the fact of how JS defines undefined and most of the time understands undefined, but is refine-able as well.

Concluding...

JS also knows about null - which I use as a defined undefined vs. the undefined undefined. That sounds weird, but is my solution for the issue @maze1980 may have and tries to find a solution for. If I code something, it always - when I'm at fully capacity - intentional and has a reason / purpose to serve... and defined - otherwise it would be a waste of my time and I would not code it - and so I make a distinction between undefined undefined: undefined and defined undefined: null. This prevents me from running into this issue and provides me with the advantage of detecting when I missed something - was obviously not at full capacity... ;-)