Sadly, the author doesn’t go into much detail. I think that python gets it wrong.
Here’s the thing: I’m a visually oriented person. I imagine a stack as - well - a stack. If you ask me to draw a stack, I will draw it with the last frame on top.
If you would ask me to write down an exception history, I’d write. “A while evaluating B while…”.
If you turn the whole thing upside down, it confuses the hell out of me.
Scrolling is cheap.
Also, bonus points for getting mad through garybernhardt, who I really dislike. Because he gets people to rant without interacting with the issue enough.
Last frame on top also keeps the last frames (usually by far the most important) in roughly the same early character locations in things like log records, allowing you to do things like easily group by the first hundred characters of a collection of stack traces to see what errors/exceptions you’re encountering with the most frequency.
I don’t believe there’s a “correct” way to print tracebacks. Neither method conveys more information than the other and they’re both cheap to implement. Sounds more like a religious thing to me.
I just argued why the “traditional” method conveys information better for me (not more, but better). I probably does better for others - that’s not religious, but a matter of preference. So… a preference would be great :D.
Build output is backwards too. After screenfuls of compiler errors, I have to scroll back and find the first error.
Isn’t that more of an issue of not failing at the first error?
It’s weird anyways: rustc for example might report multiple errors at the same time (e.g. all type check errors), I still work them through top to bottom, although they all have the same importance and I could work bottom to top just as well.
not failing at the first error?
I can only think of one compiler (many years ago) that failed on the first error. It was very annoying. You’d have to recompile everything to see the NEXT error. Sometimes after making lots of breaking changes, you just want to see all the errors and fix them all at once.
Although one error can cause other errors, I usually see more than one “independent” error in the build output after I’ve been editing for a while.
It’s probably just me, but this article reminded me of how much I hate going through the build output to find the first error.
clang supports limiting errors with a command line flag.
If your stacktrace is in a file then you’re looking at the most important part as soon as you open it.
The real problem is that consoles scroll output the wrong way :)
Does Emacs C-x ` handle Python stacktraces correctly yet?