On many architectures almost any stack overrun will overwrite the frame pointer in C, resulting in a corrupted stack trace.
As mentioned in my second comment, I slightly conflated what C and JVM crashes look like – the comparison was poor.
> I've honestly no idea what you are talking about here. Java code swamped in gotos?
Yes, the JVM has goto and your favourite compiler probably emits it, it's just not exposed in Java. If we're to compare the similarity of debugging a crash on the JVM to one on the "JSVM", then we cannot discount the complexity of the toolchain producing the target JVM code. If we assume that toolchain is bug free, then we must also assume a similar compiler targeting the JSVM is bug-free. At which point the OP should not discuss trying to debug Javascript – in this scenario it should never be required.
If instead we assume the JVM compiler and the JSVM compiler are not bug-free, then we must account for the debuggability of their languages. In the JVM one works in terms of stack offsets and goto (see http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi... ) while useful constructs like "string key -> Object map" are totally missing (aka. a Javascript object), and all complex expressions are lowered to a long series of basic instructions, all involving stack manipulation.
In contrast a JSVM-targeting compiler can emit human-readable expressions and control structures, has no access to goto or stack manipulation instructions, and short-term architectural choices about how those constructs are further lowered is not baked into the language. Each individual implementation can choose their own approach, and improve on it in the future without requiring recompilation.
The result is that given a bad toolchain (and currently the JS transpilers really are all quite bad, and JS lacks some trivial features like source maps), the JSVM is an inherently more human-friendly debug target with less assumptions about the runtime environment. By now it should be clear that to compare you must discount the short term comparitive maturity of existing JVM compilers – an excellent idea when making long term architecture decisions. Additionally since in JS there are no threads contributing to shared state, code flow is also easier to understand.
[Edit] If we're to discuss anything like supplanting Javascript as the language for the web in the long term, let's not resort to 1980s architectural notions about static, totally inaccessible binary formats. Approaches like PyPy are far more interesting – given a minimally modified existing language, annotate it such that an implementation can build an optimizing interpreter for any language implemented in that existing language. Imagine Javascript being that existing language, and suddenly all the upheaval and backwards compatibility destruction disappears. Your JS-authored language interpreter could still function in old browsers, it'd just execute more slowly.
Maybe eventually we will have 'sufficiently smart transpilers' and interactive debuggers for languages that target javascript and don't expose the 'JSVM' but that is not the case at the moment. Mozilla said "And if your problem is with JavaScript as a language, you can already use a myriad of languages that reliably compile to it", i.e. if you don't like javascript you don't need to use javascript. This is what I was responding to, because I don't see it being true in the near future (next several years at least).
Right now source mapping is only working between uncompressed/combined JavaScript to compressed/uncombined JavaScript
Which was exactly my point. The tools for targeting javascript from other languages are non-existent at the moment, never mind mature enough that I would want to rely on them in production.
As an aside, am I the only person who reads things like this and is filled with a sense of foreboding:
The spec mentions cross site script inclusion issues that could arise from the consumption of a source map. To mitigate this it's recommended that you prepend the first line of your source map with ")]}" to deliberately invalidate JavaScript so a syntax error will be thrown.
As mentioned in my second comment, I slightly conflated what C and JVM crashes look like – the comparison was poor.
> I've honestly no idea what you are talking about here. Java code swamped in gotos?
Yes, the JVM has goto and your favourite compiler probably emits it, it's just not exposed in Java. If we're to compare the similarity of debugging a crash on the JVM to one on the "JSVM", then we cannot discount the complexity of the toolchain producing the target JVM code. If we assume that toolchain is bug free, then we must also assume a similar compiler targeting the JSVM is bug-free. At which point the OP should not discuss trying to debug Javascript – in this scenario it should never be required.
If instead we assume the JVM compiler and the JSVM compiler are not bug-free, then we must account for the debuggability of their languages. In the JVM one works in terms of stack offsets and goto (see http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi... ) while useful constructs like "string key -> Object map" are totally missing (aka. a Javascript object), and all complex expressions are lowered to a long series of basic instructions, all involving stack manipulation.
In contrast a JSVM-targeting compiler can emit human-readable expressions and control structures, has no access to goto or stack manipulation instructions, and short-term architectural choices about how those constructs are further lowered is not baked into the language. Each individual implementation can choose their own approach, and improve on it in the future without requiring recompilation.
The result is that given a bad toolchain (and currently the JS transpilers really are all quite bad, and JS lacks some trivial features like source maps), the JSVM is an inherently more human-friendly debug target with less assumptions about the runtime environment. By now it should be clear that to compare you must discount the short term comparitive maturity of existing JVM compilers – an excellent idea when making long term architecture decisions. Additionally since in JS there are no threads contributing to shared state, code flow is also easier to understand.
[Edit] If we're to discuss anything like supplanting Javascript as the language for the web in the long term, let's not resort to 1980s architectural notions about static, totally inaccessible binary formats. Approaches like PyPy are far more interesting – given a minimally modified existing language, annotate it such that an implementation can build an optimizing interpreter for any language implemented in that existing language. Imagine Javascript being that existing language, and suddenly all the upheaval and backwards compatibility destruction disappears. Your JS-authored language interpreter could still function in old browsers, it'd just execute more slowly.