Hacker News Reader

Comment by systems | Hacker News Reader

Julia is not a scripting language, or in other word, Julia scoping rule are not scripting friendly

currently if in a file i have

    local s = 0

    for i = 1:10
        t = s + i
        s = t
        println("$s")
    end

    println("$s")

and I execute this file, I will get an error

    ERROR: LoadError: UndefVarError: s not defined

View on HN

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")

    let s = 0

        for i ∈ 1:10
            t = s + i
            s = t
            println("$s")
        end

        println("$s")
    end

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.

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

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.

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.

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/

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.

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.

sorry - why would you expect a local declaration to be in scope for other code?

s is defined in the statement and then is undefined out of that statement because there is no other scope for it - it's at top level. just write s =0 and all is well as s exist in the global scope where your code lives as well...

OP should've written just `s=0`, yes. Because showcases their complaint better since, although works in REPL, also fails when in file. (It's also the example given in docs[1].) Now, it looks like they tried to make it fail.

[1]: https://docs.julialang.org/en/v1/manual/variables-and-scopin...

Shouldn't the language flag that using local in that scope is an error then?

Yes - the error reporting has always been one of my complaints about Julia (although it's hugely improved). I think that the Julia dev community are really really interested in cool language features and optimisations but much less empathic with numpties like me that can't understand why their code crashes. More work on this would be much better.

Although it's a bit of an challenge to get the interpreter to understand which thing that's out of scope should be in scope for the code to work (because it's all out of scope..)

https://github.com/JuliaLang/julia/issues/57483 yes, yes it should.

well done that man

Right, but did anyone say the Julia was a scripting language?

Reply on news.ycombinator.com