I find that every time I get an error message in (VScode) Julia, I have to scroll up to the top and then read top down. The first many lines of what is visible are generally not useful at all. This is particularly bad with VSCodeServer since there are many additional lines to scroll past. The error is more-or-less always in a line of user code, so it makes sense for that to be visible first.
Python trace backs are easier to read since the line that triggered the error is immediately visible, and I scroll up for more context.
Matlab error messages are typically concise and line triggering is discernible without scrolling.
From what I can gather of Rust, you can also see the line that caused an error without scrolling.
99% of the time I reach for the mouse when developing Julia is to scroll error messages to the top and read down.
It would seem a lot more ergonomic and friendly if we simply reversed the order of these error messages to read from bottom to top.
The thing that’s a little weird about this is that REPLs kind of force people to read bottom to top. I think our current behavior is probably better for a program run from command line, but worse for repl development. One solution would be to have the REPL (instead of the language) reverse this.
Slightly related is that IMO the colors 1.6 adds to stack traces help with this a lot.
On the contrary, I’ve always found Python’s tracebacks to be counter-intuitive. The Julia REPL is printing the stacktrace—in other words, the stack of function calls. The most recent call should be on top of the stack, and should therefore be printed at the top.
Another reason Python’s tracebacks are counter-intuitive is because I always read text from top to bottom. Python error messages are the only time I’m forced to read upwards.
Just to add a data point: Ruby printed stack-traces the same way as Julia for most of its existence, but has recently changed and adopted the Python bottom-to-top format.
I also agree that, when it comes to tooling/IDEs/editors, order shouldn’t really matter so long as the format is consistent and well specified. Then it is up to the tooling how it wants to parse and present the trace.
So what are the most common use cases where a Julia user would be likely to encounter a stack trace without a tool to help make sense of it? CLI scripts and the REPL seem like the most obvious answers, and in both cases it seems like presenting the most relevant lines from a stack trace directly to where the user’s focus lies (at the blinking cursor at the bottom of the screen) makes the most sense.
Completely agree. Here’s an illustration of the point (code here, with top two showing status quo, and bottom one showing how it might look if flipped. I think the latter is clearly the better UX
Edit: note that the same problem occurs when running from command line as julia temp.jl, in fact if anything it’s slightly worse as have to scroll up an additional 5 lines:
I’ve been using it for about a week now and I really like it. It has decreased how much I need to scroll from “almost all the time” to “very rarely or only sometimes”. I’m even able to use VSCode or neovim with a 70-30 horizontal split and just the last few lines tells me what I need to change in my code.
It doesn’t work with tests yet, I think I’ll have to overload more functions in Base for that. I figured I’d share to see if others were interested in using it.
