My personal didactic explanation of how that is the way it is: Scope of loops · JuliaNotes.jl
3 Likes
You can go read some of the threads on this topic. They are numerous and heated. You may be able to see why it ended up with a compromise.
4 Likes
The one reason for that difference is: interactive vs. non-interactive usage.
OK, I accept the compromise and am waiting for the fallout. So what linter should we concentrate on?
I think that it would be great to have a “performance tips” linter/package, to which new users in particular should be directed from the top of the tips page.
That said, after a while writing Julia these non-constant global assignments become like carbons with five covalent bonds, one simply get uncomfortable just at starring at them.
2 Likes
Very nice write-up Leandro. Quote: “nobody writes critical code directly to the REPL” probably should be something like a motto, to encourage beginners not to write critical code directly to the REPL. I still often dump code into the REPL when I should know better…
2 Likes
Yes, it is very common to fall into this problem when benchmarking a piece of code which may be critical in a larger context. The compromise of the scopes allow we to copy and paste the code to the REPL and causes this possible benchmarking artifact. But the real code, written in a function, in a separate file, won’t be type unstable without warning. That is more about training how to properly benchmark things than actually a scoping problem. Benchmarking is tricky many times, not only because of this.
1 Like
Well, it’s good that the most recent version of vscode-julia can accept output from linters, I felt like that was one thing that was missing from the juno → vscode move.
Personally, I would love to see something like Rust’s clippy, which given Rust’s complexity, helps its overall developer experience tremendously:
https://github.com/rust-lang/rust-clippy
1 Like