4 ms·

Note if you're doing this in the global scope, the local declaration on `s` will cause it to functionally not exist. You can write this as either s = 0

Note if you're doing this in the global scope, the local declaration on `s` will cause it to functionally not exist. You can write this as either s = 0 for i ∈ 1:10 t = s + i global s = t println("$s") end println("$s") or let s = 0 for i ∈ 1:10 t = s + i s = t println("$s") end println("$s") end

affinepplan 2y ago
while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows
- eigenspace 2y ago
  Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness. Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!" But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting. I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.
  - catgary 2y ago
    See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.
    - kbarros 2y ago
      As we've been discussing in another thread, it's possible! One can "opt out" of Julia's dynamic behaviors on a function-by-function basis using the JET.jl tool for static analysis: https://aviatesk.github.io/JET.jl/dev/optanalysis/ https://aviatesk.github.io/JET.jl/dev/optanalysis/ Why not make this the default everywhere? Well, there are a lot of scientific use cases where it's convenient to have Python-style dynamic typing and interactivity. A cool thing about Julia is that it allows that, while _also_ allowing to achieve high-performance, all within a single language. For the record, I do also love the static type system and overall design of Rust. But for my day job (research in numerical methods and computational physics), I find Julia to be the most efficient way to get the job done -- rapid algorithm prototyping, data analysis, plot generation, etc.
      - snicker7 2y ago
        It may be worthwhile to understand where dynamic typing is helpful since this gets mentioned a lot. Python and other dynamic languages are increasingly reliant on static type checkers.
forgotpwd16 2y ago
Another alternative is putting the code in a function and calling that function. function test() s = 0 for i = 1:10 t = s + i s = t println("$s") end println("$s") end test() For anyone curious, the rationale for this scoping is explained in the docs. Essentially it's to prevent the so-called spooky action at distance.

affinepplan 2y ago

while of course you're correct on a technical level, I do tend to agree with the statement that Julia is not particularly friendly to bash-scripting-heavy workflows

eigenspace 2y ago
Meh. For my purposes, Julia strikes a quite nice balance of fussiness versus permissiveness. Sure, there's things where I find it too fussy and I wish it'd go "yeah yeah I get what you mean" and there's also things where I find myself thinking "man, I really wish you had complained to me about that, it was clearly a bug / bad style!" But all-in-all, I find it's a language that mostly gets out of my way and lets me code, which I find very useful and nice for scripting. I think if one finds things like scoping rules annoying for scripting, that might just come down to just knowing and being more familiar with another language that has different rules.
- catgary 2y ago
  See, I find it the opposite - superficially fussy, but it lets the silliest things slide. I don’t want my function to struggle with type instability in some contexts (perhaps only showing up deep in a physics simulation or motion planning algorithm) and allocate a bunch of memory, I don’t want it to compile in the first place if that’s possible.
  - kbarros 2y ago
    As we've been discussing in another thread, it's possible! One can "opt out" of Julia's dynamic behaviors on a function-by-function basis using the JET.jl tool for static analysis: https://aviatesk.github.io/JET.jl/dev/optanalysis/ https://aviatesk.github.io/JET.jl/dev/optanalysis/ Why not make this the default everywhere? Well, there are a lot of scientific use cases where it's convenient to have Python-style dynamic typing and interactivity. A cool thing about Julia is that it allows that, while _also_ allowing to achieve high-performance, all within a single language. For the record, I do also love the static type system and overall design of Rust. But for my day job (research in numerical methods and computational physics), I find Julia to be the most efficient way to get the job done -- rapid algorithm prototyping, data analysis, plot generation, etc.
    - snicker7 2y ago
      It may be worthwhile to understand where dynamic typing is helpful since this gets mentioned a lot. Python and other dynamic languages are increasingly reliant on static type checkers.

forgotpwd16 2y ago

Another alternative is putting the code in a function and calling that function. function test() s = 0 for i = 1:10 t = s + i s = t println("$s") end println("$s") end test() For anyone curious, the rationale for this scoping is explained in the docs. Essentially it's to prevent the so-called spooky action at distance.